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FUSION OF PROCESS PERFORMANCE MONITORING WITH 
PROCESS EQUIPMENT MONITORING AND CONTROL 

The present invention relates generally to process control systems within process 
> Plants and, more particularly, to a coordinated system that uses multiple types of data 
from different and divergent data sources, such as those associated with equipment 
momtonng, process control monitoring and performance monitoring, to assist in and 
enhance asset utilization in a process control plant or environment 

Process control systems, like those used in chemical, petroleum or other 
processes, typically include one or more centralized or decentralized process controller, 
communicatively coupled to at least one host or operator workstation and to one or more 
process control and instrumentation devices, such as field devices, via analog, digital or 
combmed analog/digital buses. Field devices, which may be, for example valves, valve 
posmoners, switches, transmitters, and sensors (e.g., temperature, pressure and flow rate 
sensors), perform functions within the process such as opening or closing valves and 
measuring process parameters. The process controller receives signals indicative of 
process measurements or process variables made by or associated with the field devices 
and/or other information pertaining to the field devices, uses this information to 
implement a control routine and then generates control signals which are sent over one 
or more of the buses to the field device, to control the operation of the process 
Information from the field devices and the controller is typically made available to one 
or more applications executed by an operator workstation to enable an operator to 
perform desired functions with respect to the process, such as viewing the current state 
of the process, modifying the operation of the process, etc. 

While a typical process control system has many process control and 
mstrumentation devices, such as valves, transmitters, sensors, etc. connected to one or 
more process controllers which execute software that controls these devices during the 
operation of the process, there are many other supporting devices which are also 
necessary for or related to process operation. These additional devices include for 
exam P l e , P owersupplyequipment,powergenerationanddistributionequipment,rotating 



equipment such as turbines, etc., which are located at numerous places in a typical plant. 
While this additional equipment does not necessarily create or use process variables and, 
in many instances, is not controlled or even coupled to a process controller for the 
purpose of affecting the process operation, this equipment is nevertheless important to 
and ultimately necessary for proper operation of the process. In the past however, process 
controllers were not necessarily aware of these other devices or the process controllers 
simply assumed that these devices were operating properly when performing process 
control. 

Still further, many process plants have other computers associated therewith 
which execute applications related to business functions or maintenance functions. For 
example, some plants include computers which execute applications associated with 
ordering raw materials, replacement parts or devices for the plant, applications related to 
forecasting sales and production needs, etc. Likewise, many process plants, and 
especially those which use smart field devices, include equipment monitoring 
applications which are used to help monitor and maintain the devices within the plant 
regardless of whether these devices are process control and instrumentation devices or 
are other types of devices. For example, the Asset Management Solutions (AMS) 
application sold by Fisher-Rosemount Systems, Inc. enables communication with and 
stores data pertaining to field devices to ascertain and track the operating state of the field 
devices. An example of such a system is disclosed in U.S. Patent Number 5,960,214 
entitled "Integrated Communication Network for use in a Field Device Management 
System." In some instances, the AMS application may be used to communicate with 
devices to change parameters within the device, to cause the device to run applications 
on itself, such as self calibration routines or self diagnostic routines, to obtain information 
about the status or health of the device, etc. This information may be stored and used by 
a maintenance person to" monitor and maintain these devices. Likewise, there are other 
types of applications which are used to monitor other types of devices, such as rotating 
equipment and power generation and supply devices. These other applications are 
sometimes available to the maintenance persons and are used to monitor and maintain the 
devices within a process plant. In many cases, however, outside service organizations 



-2- 



237974©A_L> 



m3yperfon BS enncesre 1 a« e d, 0m o, 1 i,ori n gproce SS perfo™a n ce m de q uip ID e n tIn tt ,« e 
cases, the outside service organizations acquire the data they need, run typically 
propnetary applications to analyze the data and merely provide results and 

re.otn^endationstotiaeproeessplan.persom.el.WMtehelpfa.ti.epIantpersonnelhave 
Itttle or no ability to view the raw data measured or to use the analysis data in any other 



manner. 
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ITtus, in me laical plant or process, the-functions associated with the process 
control activities, the device and equipment maintenance and monitoring activities, and 
the busrness activities such as process performance monitoring are separated, bom in the 
' location in which these activities take place and in the personnel who typically perform 
these activities. Furthermore, the different peop.e involved in these different (unctions 
generally use different tools, such as different apphcations nm on different computers to 
perform the different (unctions. In many instances, these d(fferen( tools collect or use 
Afferent types of data associated win, or collected fa, (he different devices within the 
process and are set up different* «o col.ect me data they need. For example, pmcess 
control operators who generally oversee the day to day operation of the process and who 
amprmtanly responsible for assuring the quality^ continuity of the process operation 
typtcally affect me process by setting and changing se, points within (he process nming 

loop S „fthep ro cess, S chednlingprocess„peratio„ssuchasba,choperati 0 ns,e,c. These 
process control operators may use available tools for diagnosing and correcting process 
control problems within a process control system, including, for example, auto-tone* 
loop analyzers, neural network systems, etc. Process control operators also receive 
process variable infonnation from theprocess via one or morepmcess control.ers which 
P~v.de infonnation to the operate, about the operation of thepmcess, including alarms 
generated within the process. This information may be provided to the process contro. 
operator via a standard user interface. 

Still further, it is currently known to provide an expen engine tha. nses process 
control variables and limited information about the operating condition of the control, 
routines or Amotion blocks or modules associated with process control routines to detect 
poorly operating toops and to pmvideinformation to an operator about suggested courses 
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of action to correct the problem. Such an expert engine is disclosed in U.S. Patent 
Application Serial Number 09/256,585 entitled 'Diagnostics in a Process Control 
System," which was filed on February 22, 1999 and in U.S. Patent Application Serial 
Number 09/499,445 entitled "Diagnostic Expert in a Process Control System," which was 
5 filed on February 7, 2000, both of which are hereby expressly incorporated by reference 
herein. Likewise, it is known to run control optimizers, such as real time optimizers, 
within a plant to optimize the control activities of the process plant. Such optimizers 
typically use complex models of the plant to predict how inputs may be changed to 
optimize operation of the plant with respect to some desired optimization variable such 
10 as, for example, profit. In many cases, however, these optimizers are provided by outside 
service organizations and, thus, are not directly accessible to other areas of the plant. 

On the other hand, maintenance personnel who are primarily responsible for 
assuring that the actual equipment within the process is operating efficiently and for 
repairing and replacing malfunctioning equipment, . use tools such as maintenance 
15 interfaces, the AMS application discussed above, as well and many other diagnostic tools 
which provide information about operating states of the devices within the process. 
Maintenance persons also schedule maintenance activities which may require shut down 
of portions of the plant. For many newer types of process devices and equipment, 
generally called smart field devices, the devices themselves may include detection and 
20 diagnostic tools which automatically sense problems with the operation of the device and 
automatically report these problems to a maintenance person via a standard maintenance 
interface. For example, the AMS software reports device status and diagnostic 
information to the maintenance person and provides communication and other tools that 
enable the maintenance person to determine what is happening in devices and to access 
25 device information provided by the devices. Typically, maintenance interfaces and 
maintenance personnel are located apart from process control operators, although this is 
not always the case. For example, in some process plants, process control operators may 
perform the duties of maintenance persons or vice versa, or the different people 
responsible for these functions may use the same interface. 

-4 - 
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SU1I further, petsons responsible and applications used for business applications 

such as choosing which products ,o manufacmre, wha, variab.es «o optimize widun «he 
Planum ^-P™cessperfor m ance ra easuresa re r wicaIIylocal e dinof5cesoflhe 
Plan, «ha, are remo.e from both fhe process conbu, interfaces and .he maintenance 
interfaces. Likewise, managers or other persons may wan, ,„ have access to certain 
■nfotmation within the pmcess plart, font rentote locations or front outer computer 
systems associated with the process p.an. for use in evening the p,ant operation and 
in making long tetm strategic decisions. 

Because, for the tnos, pan, very different applications used to perfotnt the 
dtfferen, functions wifhin a plan, e.g., process conuo. opemtions. ntaintenance 

op^a,,onsandbusinessoperaHonsar.separa,ed, ft ed,fferen,applicationsused 
dtfferen, Usks are no, integra.ed and, Urns, do no, share data or infonnation. In fact, 
many piants on* include sotne, bu, no, aU, of dtese differen, types of appneations. to 
many cases, some of the .asks, such as monitoring equipment, testing <he operation of 
devces, detenrtining if me p.an, is running in an optima) manner, em. are perfonned by 
ou,s,de consul or service companies who measure ,he data needed, perfonn an 
analysis and men provide only „e result of me analysis back ,„ the p,an, personnel In 

mesecases.meda^is^ica.lyconectedand stored inaproprieuuymannerandis.re.y 
made available to the plant personnel for outer reasons. 

Stil, luzuter, even if all of the applications are located within a plan,, because 

d,fTere„, personnel use these differen, apphcations and analysis ,ools and because fhese 

•cols are generally ,oca,ed a, different hamware locations wi.hfn the plan, mere is Me 

,f any flow of infonnauon from one functiona. area of me p.an, ,o another, even when 

tins mfonnation may he useful to other functions wifhin the plan,. For example a tool 

such as a rotating equipment data analysis too,, maybeused by a maintenance petson to 

detect a poorly functioning power generator or piece of rotating equipment (based on 

non-process variab.e type data). This foo, may de.ee, a prob.em and alert the 

matntenaoe. person ma, the device needs ,o be calibrated, repaired or replaced 

However, me process control operator (either a human or a software expert) does no,' 



have the benefit of this information, even though the poorly operating device 
may be causing a problem that is affecting a loop or some other component 
which is being monitored by the process control operation. Likewise, the 
business person is not aware of this fact, even though the malfunctioning device 
may be critical to and may be preventing optimization of the plant in a manner 
that the business person may desire. Because the process control expert is 
unaware of a device problem which may be ultimately causing poor 
performance of a loop or unit in the process control system and because the 
process control operator or expert assumes that this equipment is operating 
perfectly, the process control expert may mis-diagnose the problem it detects 
within the process control loop or may try to apply a tool, such as a loop tuner, 
which could never actually correct the problem. Likewise, the business person 
may make a business decision to run the plant in a manner that will not achieve 
the desired business effects (such as optimizing profits) because of the 
malfunctioning device. 

Due to the abundance of data analysis and other detection and diagnostic 
tools available in the process control environment, either in the plant itself or 
via outside service companies or consultants, there is a lot of information about 
the health and performance of devices available to the maintenance person 
which could be helpful to the process operator and the business persons. 
Similarly, there is a lot of information available to the process operator about 
the current operational status of the process control loops and other routines 
which may be helpful to the maintenance person or to the business person. 
Likewise, there is information generated by or used in the course of performing 
the business functions which could be helpful to the maintenance person or the 
process control operator in optimizing the operation of the process. However, 
in the past, because these functions were separated, the information generated 
or collected in one functional area was not used at all, or not used very well in 

6 
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other functional areas which led to an overall sub-optimal use of the assets 
within process plants. 

According to a first aspect of the invention, we provide a process control 
system within a plant including process equipment monitoring devices that 
collect equipment data, process control monitoring devices that collect process 
control data, process models adapted to perform process performance 
monitoring to generate process performance data and a computer system that 
implements a software routine that uses two or more of the equipment data, the 
process control data and the process performance data to perform a function 
within the plant. 

According to a second aspect of the invention, we provide a method of 
operating a process control system within a plant including the steps of 
collecting equipment data related to the status of equipment within the plant, 
collecting process control data related to the status of process control activities 
within the plant, collecting process performance data relating to the 
performance of the process and using two or more of the equipment data, the 
process control data and the process performance data to perform a further 
function within the plant. 

According to a third aspect of the invention, we provide a process 
control system comprising multiple process control devices; one or more 
controllers, one or more user interfaces, one or more data collection routines 
implemented on processing devices that collect process control data, equipment 
data and process performance data and a condition monitoring routine 
communicatively connected to the data collection routines to accept and 
process the process control data, the equipment data and the process 
performance data collected by the data collection routines to perform condition 
monitoring within the process control system; 

wherein the process control devices, controllers and user interfaces are 
communicatively connected via one or more communication networks and 

7 
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wherein the data collection routines are configured to transparently accept data 
from multiple different source types within the process control system. 

According to a fourth aspect of the invention, we provide a process 
control system comprising multiple process control devices, one or more 
controllers, one or more user interfaces, a communication network that 
interconnects the one or more controllers and the one or more user interfaces, a 
database that stores equipment and process control strategy configuration 
information pertaining to the configuration of the process control system, one 
or more data collection routines implemented on processing devices that collect 
process control data, equipment data and process performance data, a condition 
monitoring routine communicatively connected to the one or more data 
collection routines to accept and process the process control data, the 
equipment data and the process performance data collected by the data 
collection routines to perform condition monitoring within the process control 
system; and a display routine that displays the equipment and process control 
strategy configuration information associated with the process control system as 
stored in the database along with condition monitoring information pertaining 
to or generated by the condition monitoring routine, via the one or more user 
interfaces. 

A process control system includes a data collection and distribution 
system that collects and stores data from different data sources, each of which 
may use its own proprietary manner of acquiring or generating the data in the 
first place. The data 
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collection and disunion system then makes the stored da* available to other 
app.tcar.ons associated with or provided in the process control system or to applications 
associated with the data sources themselves for use in any desired manner. In this 
manner, applications may use data from vastly different data soirees to provide a better 
5 v,ew or insight into the current operational stetus of a plan,, to make better or more 
complete diagnostic or financial decisions regarding the plant, «c. Thus, applications 
^ybeprovidedwnichcombineornsedatafi^previonsly disparate collection systems 
such as process control monitoring systems, equipment monitoring systems and process 

perfoHnancemodeUtodetennmeabeneroverallvieworstateofaprooessconn-olplan^ 
10 '^^erdiagnosepmWemsandtoukeorrecommendactionsinpmductionplanningand 
mamtenance within the plant For examp.e, information or data may be co.lected by 
mamtenance functions pertaining to the health, variability, performance or utilization of 
a dev.ee, loop, unit, etc. This infonnation may fl.cn be sent to and displayed to a process 
opemtorormamtena^epersontoinformaatperaonofactnTentorfctnreproblem This 
15 ^^nnationmaybeusedbyflteprocessopemtortocorrectacun^tproblcmwiflrin 
a loop or to change, for example, the plan, operating point ,o account for and ,o octree, 
for a sub-optimaHy operating device. The diagnostic apphcaoons may generate 

measurentent.con^o.anddevicemdexespeminmgtonon-process variab.es, snchasflte 
heaJth of a device. These equipment performance indexes maybe determined from 
models calculating key performance variables, such as efficiency tutd cos, of production 
A process comrol expert may use these measurement, control and device indexes along 
with process variable data to optimize operation of the process. 

Using the disclosed data collection and distribution system, process variable date 
and non-process variab.e date may be combined, for example, to generate process 
models. Likewise, Are detection of a device problem, such as one which requires 

shu,downoffl,eprocess,mayca„sebnsiness software to automaticallyorderreplacemen. 
parts or alen fltebusiness person tin,, chosen strategic actions will not produce the desired 
resuhs due to the actua. state of the p.ant The change of a con.ro. strategy performed 
wtflnn the process comm. function may cause business software to automatical* order 
new or mfferen. raw materials. There are, of course, many other types of applications to 
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which the fusion data related to process control, equipment monitoring and performance 
monitoring data can be an aid by providing different and more complete information 
about the status of the assets within a process control plant to all areas of the process 

P lant An embodiment of the present invention will now be described by way of 
example only with reference to the accompanying drawings wherein: 

Fig. 1 is a block diagram of a process control plant having numerous equipment 
and process monitoring devices configured to receive and send data to one or more data 
collection and distribution stations, which may send this data to viewing and diagnostic 
routines that use the collected data to provide numerous benefits in the process control 
10 plant; 

Fig. 2 is a functional diagram illustrating data flow between various data sources 
and applications which combine this data to perform various functions; 

hig. 3 is a more detailed data flow diagram illustrating the data flow from 
numerous sources of equipment monitoring, process device monitoring and process 
15 performance monitoring data to a data collection and distribution system which then 
provides this data to an asset utilization and production planning suite that fuses the 
collected data to create more complete views and/or better diagnostics for a process 
control plant; 

Fig. 4 is a block diagram illustrating an architecture for one embodiment of a 
process control environment that implements a data collection and distribution system 
associated with multiple disparate data sources; 

Figs. 5 A and 5B depict one manner of organizing and storing data collected from 
numerous data sources in a configuration database in a manner that makes this data 
commonly available to other applications; 
25 Fig. 6 is a diagram illustrating an application that enables a user to configure a 

data collection and distribution system to automatically provide collected data to 
applications within a process control environment in conjunction with the configuration 
system of Fig. 5; 

Fig. 7A is a block diagram of a model used to simulate the operation of an area 
30 within a plant; 

10 
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Fig. 7B is a block diagram of a model led to simulate the operation of a unit 
within the area model of Fig. 7A; 

Fig. 8 is an exemplary depiction of a display reputing a ami within a process 
control system Ota, may be displayed by a graphical user interface using dara collected 
5 from different data sources; 

Fig. 9 is an exemplary graphical display that may beprovided by agraphical user 
interface using data collected from different data sources; 
Fig.lOisanexem P larydepict^^ 

---^-toenableausertoviewaudittrailinfonnat^ 
1U sources; 

Fig. 1 1 is an exemplary depiction of a display that may be provided by a graphical 
usermterface to enable a user to perform a more detailed analysis of data collected from 
Afferent data sources and used to generate one or more indexes for a device; 

Fig. 12 is yet another exemplary depiction of a display that may be provided by 
a graphical user interface to enable a user to quickly investigate information within a 
plant; 

FiglSiaanexernplarydepictionofadiagnosticdispIaythatmaybeprovidedby 
a graphical user interface that enables a user to analyze the performance and/or status of 
^ one or more process control lo ops or other process control entities using data coUected 
20 from different data sources; 

Fig. 14 is an exemplary depiction of a diagnostic display that may beprovided by 
a graphical user interface that enables a user to analyse the performance and/or status of 
one or more process control loops or other process control entities; 

Fig. 1 5 is still another exemplary depiction of a display that may be provided by 
a graphical user interface to enable a user to track or generate work orders; and 

F,g. 16 illustrates a display showing a spectral plot of vibration of an element 
w.thm a rotary device that may have been generated by an external data source. 

Referring now to Fig. 1 , a typical process control plant 1 0 includes a number of 
busmess and other computer systems interconnected with a number of control and 
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maintenance systems by one or more communication networks. The illustrated process 
control plant 10 also includes one or more process control systems 12 and 14. The 
process control system 12 may be a traditional process control system such as a 
PRO VOX or RS3 system or any other DCS. The system 12 illustrated in Fig. 1 includes 
an operator interface 1 2A coupled to a controller 1 2B and to input/output (I/O) cards 1 2C 
which, in turn, are coupled to various field devices such as analog and Highway 
Addressable Remote Transmitter (HART) field devices 15. The process control system 
14, which may be a distributed process control system, includes one or more operator 
interfaces 14A coupled to one or more distributed controllers 14B via a bus, such as an 
Ethernet bus. The controllers 14B maybe, for example, Delta V™ controllers sold by 
Fisher-Rosemount Systems, Inc. of Austin, Tex as or any other desired type of controllers. 
The controllers 14B are connected via I/O devices to one or more field devices 16, such 
as for example, HART or Fieldbus field devices or any other smart or non-smart field 
devices including, for example, those that use any of the PROFIBUS®, WORLDFIP®, 
Device-Net®, AS-Interface and CAN protocols. As is known, the field devices 16 may 
provide analog or digital information to the controllers 14B related to process variables 
as well as to other device information. The operator interfaces 14A may store and 
execute tools available to the process control operator for controlling the operation of the 
process including, for example, control optimizers, diagnostic experts, neural networks, 
tuners, etc. 

Still fiirther, maintenance systems, such as computers executing the AMS 
application or any other device or equipment monitoring and communication applications 
may be connected to the process control systems 12 and 14 or to the individual devices 
therein to perform maintenance and monitoring activities. For example, a maintenance 
computer 1 8 may be connected to the controller 12B and/or to the devices 15 via any 
desired communication lines or networks (including wireless or handheld device 
networks) to communicate with and, in some instances, reconfigure or perform other 
maintenance activities on the devices 15. Similarly, maintenance applications such as the 
AMS application may be installed in and executed by one or more of the user interfaces 
14A associated with the distributed process control system 14 to perform maintenance 
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and monitoring functions, including data collection related to the operating status of the 
devices 16. 

The illustrated process control plant 1 0 also includes various rotating equipment 
20, such as turbines, motors, etc. which are connected to a maintenance computer 22 via 
■ some permanent or temporary communication link (such as a bus, a wireless 
communication system or hand held devices which are connected to the equipment 20 
to take readings and are then removed). The maintenance computer 22 may store and 
execute ^wnmomtormg and diagnostic applications 23 pmvided by, for example, ^ 
Systems or other any other known applications used to diagnose, monitor and optimize 
the operating state of the rotating equipment 20. Maintenance personnel usually use the 
applications 23 to maintain and oversee the performance of rotating equipment 20 in the 
plant 10, to determine problems with the rotating equipment 20 and to determine when 
and if the rotating equipment 20 must be repaired or replaced. In some cases, outside 
consultants or service organizations may temporary acquire or measure data pertaining 
to the equipment 20 and use this data to perform analyses for the equipment 20 to detect 
problems, poor performance or other issues effecting the equipment 20. In these cases, 
the computers running the analyses may not be connected to the rest of the system 1 0 via 
any communication line or may be connected only temporarily. 

Sirmlarly, apower generation and ^ 
and distribution equipment 25 associated with the plant 1 0 is connected via, for example 
a bus, to another computer 26 which runs and oversees the operation of the pow CT 
generating and distribution equipment 25 within the plant 10. The computer 26 may 
execute known power control and diagnostics applications 27 such a as those provided 
by, for example, Liebert and ASCO or other service companies to control and maintain 
the power generation and distribution equipment 25. Again, in many cases, outside 
consultants or service organizations may temporary acquire or measure data pertaining 
to the equipment 25 and use this data to perform analyses for the equipment 25 to detect 
problems, poor performance or other issues effecting the equipment 25. In these cases 
the computers (such as the computer 26) rnnning the analyses may not be connected to 
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the rest of the system 10 via any communication line or may be connected only 
temporarily. 

Of course, any other equipment and process control devices could be attached to 
or be part of the plant 1 0 and the system described herein is not limited to the equipment 
. 5 specifically illustrated in Fig. 1 but can, instead or in addition, include any other types of 
process control equipment or devices. 

In the past, the various process control systems 12 and 14 and the power 
generating and maintenance systems 22 and 26 have not been interconnected with each 
other in a manner that enables them to share data generated in or collected by each of 

10 these systems in a useful manner. As a result, each of the different functions such as the 
process control functions, power generation functions and rotating equipment functions 
have operated on the assumption that the other equipment within the plant which may be 
affected by or have an affect on that particular function is operating perfectly which, of 
course, is almost never the case. However, because the functions are so different and the 

15 equipment and personnel used to oversee these functions are different, there has been 
little or no meaningful data sharing between the different functional systems within the 
plant 10. 

To overcome this problem, a data collection and distribution system is provided 
to acquire data from the disparate sources of data, format this data to a common data 

20 format or structure and then provide this data, as needed to any of a suite of applications 
run at, for example, a computer system 30, or disbursed between workstations throughout 
the process control network. The suite of applications is provided to fuse or integrate the 
use of data from previously disparate and separate systems to provide a better 
measurement, viewing, control and understanding of the entire plant 10. As illustrated 

25 in Fig. 1, the computer system 30 is communicatively connected to the computers or 
interfaces associated with the various functional systems within the plant 10, including 
the process control functions 12 and 14, the maintenance functions such as those 
implemented in the computers 18, 14 A, 22 and 26 and the business functions such as 
performing process performance monitoring. In particular, the computer system 30 is 

30 communicatively connected to the traditional process control system 12 and to the 

14 . 
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mamtenance interface ,8 associated with thatcontio. system, isconnected ,o the process 
control and/or maintenance interfaces .4A of the distributed process control system 14 
.s connected ,o the rowing equipment maintenance computer 22 and ,o the power' 
generate and disuibution computer 26, all via a bns 32. The has 32 may nse any 
destred or appropriate local area network (LAN) or wide area network (WAN) protocol 
to provide conununicauons. Of course tte compnter system 30 could be connected to 
these different pans of me p.an, 10 via other communicant iinks including fixed or 
tnterminen. unks, hard-wired or over-the-air .inks or any physical medium such as one 
of wtred, wirdess, coaxial cah,e, te.ephone modem, fiber optic, optical, meteor bur*. 
<0 satelhte medium using one of a Fieldbus, IEEE 802.3, blue tooth, X.2S or X.400 
communication protocol, etc. 

As illustrated in Fig. 1, the computer 30 may also be connected via tire same or 
a d.fferen, network bus 32 to business system computers and maintenance planning 
compute* 35 and 36, which may execute, for examp,e, enterprise resource phuming 
(ERP), material resource planning (MRP), process forpafomance mo(Je] . 

accountmg, production and customer ordering systems, maintenance planning systems' 
or any other desired business applications such as parts, suppties and raw materials- 
ordenng applications, production schrfuling apphcations. ete. He computer 30 may 

^ b «°™«'rfvia,forexample,mebus32,,oap l anr»«eLA N 37,acorpomteWAN 
38 as well as to a computer system 40 that enables remote monitoring of or 
communication with the plant 10 from remote locations. 

The data collection and distribution system mentioned above may also be 
provded in tire computer 30 or maybe dispersed a, numerous locations throughout the 
process network 10 ,o acquire and pmcess data fiom any source of data such as the 

- conto..ersys,ems 1 2and 1 4, Ul emom,ori ng sys,ems22a„d26,mefiaano ia lsys,ems35 
36, etc. !f the date collection and disuibution system is located in the computer 30 it' 
may recei ve data fiom the disparate sources of data, such as the controHers, equipment 
mentoring and financial apphcations separate* using different date formats or using a 
common forma,. 1„ one embodiment, the communications over the bus 32 occur using 
theXMLprotocol. Here, date from each of the computers 12A, 18, !4A, 22, 26 35 36 
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etc. is wrapped in an XML wrapper and is sent to an XML data server which may be 
located in, for example, the computer 30. Because XML is a descriptive language, the 
server can process any type of data. At the server, if necessary, the data is encapsulated 
and mapped to a new XML wrapper, i.e., this data is mapped from one XML schema to 
5 one or more other XML schemas which are created for each of the receiving applications. 
One method of providing this communication is described in co-pending U.S. application 
Serial No. 09/902,201 filed July 1 0, 2001 , entitled "Transactional Data Communications 
for Process Control Systems" which is assigned to the assignee of this application and 
which is hereby expressly incorporated by reference herein. With this system, each data 

10 originator can wrap its data using a schema understood or convenient for that device or 
application, and each receiving application can receive the data in a different schema used 
for or understood by the receiving application. The server is configured to map one 
schema to knother schema depending on the source and destination(s) of the data. If 
desired, the server may also perform certain data processing functions or other functions 

15 based on the receipt of data. The mapping and processing function rules are set up and 
stored in the server prior to operation of suite of data integration applications described 
herein. In this manner, data may be sent from anyone application to one or more other 
applications. 

In another embodiment, the data collection and distribution applications may be 
20 dispersed throughout the network 10 and collection of data may be accomplished at 
distributed locations. The collected data may then be converted to a common format at 
the distributed locations and sent to one or more central databases for subsequent 
distribution. Thus, generally speaking, one or more data collection routines are provided 
to collect the data from disparate sources of data and to provide this data in a common 
25 or consistent format to the suite of applications which may use this data, such as the 
applications within the computer 30. The data collection and distribution applications 
are referred to herein as a data collection and distribution system while the applications 
which use the collected data (e.g. that, integrate this data) are referred to herein 
collectively as an asset utilization suite 50. 
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The applications wiflun the asse, utilization suite 50 use the collected data and 
other information generated by the process control systems 12 and > 4, the maintenance 
systems 1 8, 22 and 26 and the business and process modeling systems 35 and 36 as well 
as mfotmarion generated by data analysis tools executed in each of these systems 
5 Generally speaking, the asset utilization suite 50 may include one or mom user dispfcry 
applications such as those disclosed in U.S. Patent Application Serial Nos. 09/256 585 
or 09/499,445, and one or more diagnostic experts or outer type of expert system 
applications based on, for example, tbe OZ expert system currently provided by NEXUS 
However, the asset utilization suite 50 roayuse any outer desired type of expert system 
< mcludmg, for exam pl e, any type of data mining system. Tne asset utilization suite 50 
may also include ofter applications which integ^e data from varfous functional systems 
for anyomerputposcsuchasforuserinfotmationpurooses, for diagnostic purposes and 
for taking actions within the process plan,, such as process control actions, equipment 
replacement or repair actions, altering the type oramoun , ofpIDduc , produced based on 
finance! factors, process performance factors, etc. Thus, the data collection and 
dtsttibution system may, in one sense, operate as a data and infonnation clearinghouse 
tn the process plan, 10 to coordinate the disWburion of date or infonnation from one 
functional area, such as me maintenance area, ,o Cher functional areas, such as <he 
process control or me business functional areas. As a maul,, me asse, utihzation suite 50 
may use me collected date ,o generatenew infonnation or date which can be distributed 
,o one or more of <he compute systems associated with the different functions within the 
Plan, 10 and may execute or oversee the execution of otiter apphcationa uta, use the 
collected da,a to generate new .ypes of date to be useti wfthin (he process contiol p.an, 

In one case, <he asse, utilization suite 50 may provide a number of applications 
whtch use date from the process cohtro. functions and the equipment monitoring 
functions and, if desired, from process perfonnance monitoring functions performed 
wrthrn a process contio! nenvortc Tnese appticauons may provide a coordina,ed use, 
display for display of information or attributes abou, tire plan, ttra, use two or more of 
processcontto^a.a.processperfomrancemode.mgdate.orequipmen.moni.oringdate. 
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An application associated with the asset utilization suite 50 may also diagnose conditions 
or problems within the process control plant 10 based on data from two or more of 
process control monitoring applications, process perfonnance monitoring applications, 
and equipment monitoring applications. Still further, the applications associated with the 
5 asset utilization suite 50 may take actions within the process plant 10 in response to a 
diagnosed or detected problem or may recommend actions to be taken to a user, which 
may be any of, for example, a process control operator, a maintenance technician or a 
business person in the "front office" of the plant 1 0 who is responsible for the overall 
operation of the plant 10. 
1° More particularly, in one embodiment, the asset utilization suite 50 may include 

or execute index generation software 51 that collects or creates indexes associated with 
devices, like process control and instrumentation devices, power generation devices, 
rotating equipment, units, areas, etc, or that are associated with process control entities, 
like loops, etc. within the plant 10. These indexes can then be provided to the process 
15 control applications to help optimize process control and can be provided to the business 
software or business applications to provide the business persons more complete or 
understandable information associated with the operation of the plant 10. The asset 
utilization suite 50 can also provide maintenance data (such as device status information) 
and business data (such as data associated with scheduled orders, timeframes, etc.) to a 
20 control expert 52 associated with, for example, the process control system 1 4 to help an 
operatorperform control activities such as optimizing control. The control expert 52 may 
be located in, for example, the user interface 14A or any other computer associated with 
the control system 14 or within the computer 30 if desired. 

If desired, the control expert 52 maybe, for example, the control expert described 
25 in U.S. Patent Application Serial Numbers 09/256,585 and 09/499,445 identified above. 
However, these control experts may additionally incorporate and use data related to the 
status of devices or other hardware within the process control plant 1 0 or of performance 
data generated using process performance models in the decision making performed by 
these control experts. In particular, in the past, the software control experts generally 
30 only used process variable data and some limited device status data to make decisions or 



-18 



BNSDOCID: <GB 2379749A_I_> 



10 



15 



3 



recommendations to the process operator. With the communication provided by or 
collected by the asset utilization suite 50, especially that related to device status 
information such as that provided by the computer systems 1 g. MA. 22 and 26 and the 
data analysis tools implemented thereon, the control expert 52 can receive and 
. incorporate device status information such as health, performance, utilization and 
vanabmty information into its decision making along with process variable information. 

Additionally, the asset utilization suite 50 can provide information pertaining to 
states of devices and the operation of the control activities within the plant 10 to the 
business systems 35 and 36 where, for example, a work order generation application or 
program 54 can automatically generate work orders and order parts based on detected 
problems within the plant 10 or where supplies can be ordered based on work being 
performed. Similarly, changes in the control system detected by the asset utilization 
expert 50 may cause the business systems 35 or 36 to run applications that perform 
scheduling and supply orders using, for example, the program 54. In the same manner 
changes in customer orders etc. can be entered into the business systems 35 or 36 and this 
data can be sent to the asset utilization suite 50 and sent to the control routines or control 
• expert 52 to cause changes in the control to, for example, begin making the newly 
ordered products or to implement the changes made in the business systems 35 and 36. 

Additionally, the asset utilization suite 50 can send information to one or more 
process models used by, for example, optimizers 55 within the plant 10. For example 
a process model 56 and a control optimizer 55 can be located in the computer 14A and' 
can run one or more control optimization routines 55A, 55B, etc. Additionally or 
alternatively, process models 56 and optimizer routines 55 could be stored in and 
executedbythe computer 30 or any other computer, and the data necessary therefor could 
be sent by the asset utilization expert 50. The results of the models 56 can be input to the 
asset utilization expert 50 or a control or other expert such as the control expert 52 to 
perform modeling functions, the purpose of which will be described in more detail 
herein. Generally speaking, however, the models 56 can be used to determine process 
unit or area performance that can then be input to the optimizer routines 55 or displayed 
to a user or used for other purposes. The models 56 may be models such as those created 
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by and sold by MDC Technology located in Teeside, England or may be any other desired 
types of models. There are, of course, many other applications that can be provided 
within the plant 10 and that can use the data from the asset utilization expert 50 and the 
system described herein is not limited to the applications specifically mentioned herein. 
5 Overall, however, the asset utilization suite 50 helps to optimize the use of all of the 
assets within the plant 10 by enabling the sharing of data and coordination of assets 
between all of the functional areas of the plant 10. 

Also, generally speaking, one or more user interface routines 58 can be stored in 
and executed by one or more of the computers within the plant 10. For example, the 
10 computer 30, the user interface 14A, the business system computer 35 or any other 
computer may run a user interface routine 58. Each user interface routine 58 can receive 
or subscribe to information from the asset utilization suite 50 and may provide 
information to the asset utilization suite 50 and either the same or different sets of data 
may be sent to each of the user interface routines 58. Any one of the user interface 
15 routines 58 can provide different types of information using different screens for different 
users if so desired. For example, one of the user interface routines 58 may provide a 
screen or set of screens to a control operator or to a business person to enable that person 
to set constraints or to choose optimization variables for use in a standard control routine 
or in a control optimizer routine. The user interface routine 58 may provide a control 
guidance tool that enables a user to view the process performance and indexes created by 
the index generation software 5 1 or process performance models 56 in some coordinated 
manner. This operator guidance tool may also enable the operator or any other person 
to obtain information about the states of devices, control loops, units, etc. and to easily 
see the information related to the problems with these entities, as that information has 
25 been detected by other software within the process plant 1 0. The user interface routine 
5 8 may also provide performance monitoring screens using performance monitoring data 
provided by or generated by the tools 23 and 27, the maintenance programs such as the 
AMS application or any other maintenance programs, or as generated by the models in 
conjunction with the asset utilization suite 50. Of course, the user interface routine 58 
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may provide any user access to and enable the user to change preferences or other 
variables used in any or all functional areas of the plant 10. 
ReferrmgnowtoFig.2,as^ 

flow and communication associated with or used by a data collection and distribution 
5 ^^descn^edheremtoenab^ 

asset utilizations** 50. In particular, the diagram 100 includes the data collection and 
attribution system 102 which receives data from numerous sources of data. For 
example, a process control data source 104 (which may include traditional process 
control activities and applications such as process control and monitoring applications 
' Process control diagnostic applications, process control alarming applications, etc ) 
proves data to the data collection and distribution s^tem 102. deblock 104 may send 
data acquired by or generated by traditional or stand alone process controllers by DCSs 
by the DeltaV system, by PLCs, etc. within the process control environment. 

An equipment or process health data source 1 06 (which may include traditional 
equmment monitoring applications, equipment diagnostic applications, equipment 
alarmmg applications, abnormal situation analysis applications, environmental 
momtonng applications, etc.) also sends data to the data collection and distribution 
system 102. As a result, the source 106 may send data acquired by or generated by any 
type of traditional equipment momtonng and diagnostic applications or sources, such as 
those provided by CSI, the AMS application sold by Fisher-Rosemount Systems, Inc., 
Nexis applications, etc. 

A performance monitoring data source 1 08 (which may include perfotmance 
monnonng applications such optimization apphcarions, process models used .o monitor 
or mode! process operation, process or equipment health, etc.) also provides data ,o me 
system , 02. The data source 108 may include or provide data acquired by or generated 
by any type of performance momtonng equipment or applications. Still further a 
nnancra. or production planning data source 1 1 0 (which may include applications fta, 
perfonn financial or cost type analysis functions within the process control system, such 
as deeding how to nm the p,an, to maximize profits, ,o avoid environmental fines 
dectdmg what or how much of a product to tnake, etc.) is connected to the system , 02.' 
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Both the financial planning and the process control applications may utilize information 
provided by the same or different process models. 

Field devices 112, such as smart field devices, may provide still further data to 
the data collection and distribution system 1 02. Of course, the data provided by the field 
5 devices 1 12 may be any data measured by or generated by these field devices, including 
alarms, alerts, measurement data, calibration data, etc. Likewise, a corrosion monitoring 
data source 114 may provide data collected by or generated by corrosion monitoring 
services or applications to the collection system 102. Likewise, an alarming data source 
116 may provide data collected by or generated by advanced alarming applications or 

10 services to the system 102. The alarming data source 116 may include applications or 
services which measure or take samples, perform lab analyses and generate alarms or 
other information based on these analyses. 

It should be noted that still other data may be provided from any other sources of 
data in addition or instead of the sources of data illustrated in Fig. 2. Furthermore, the 

15 data provided by the data sources of Fig. 2 can be raw measured data, can be data 
generated by an analysis or other routine based on measured data or some combination 
of the two. Still further, it will be understood that the data provided from any or all of 
the data sources of Fig. 2 can be measured, generated or communicated in any format, 
including proprietary formats used by the different organizations or applications which 

20 might measure or generate this data. Thus, for example, different field devices 112 may 
collect and generate data in different formats and then send this data to the data collection 
and distribution system 1 02. Likewise, the financial data sources 1 1 0, the corrosion data 
sources 114, the alarming data sources 116, etc. may provide data measured in or 
generated in any standard or proprietary format, and may use any proprietary or open- 

25 code applications to measure or generate the data. Generally speaking, therefore, any 
applications or devices now used (or developed in the future for use) in a process control 
environment to measure or generate data, results, conclusions, recommendations, etc. 
may act as a data source to the data collection and distribution system 102 even if these 
data sources are partially or completely proprietary in nature. 
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The data collection and distribution system 102 will collect the data from the 
different data sources in a common format or will convert that data, once received, to a 
common format for storage and use later by other elements, devices or applications in the 
process control system. In one embodiment, the different data sources may use a data 
5 co ^°nprotocol,suc^^^ 

collection and distribution system 102. Ofcourse, the OPC or other conversion interface 
may be stored in the data collection and distribution system 1 02 or in the data sources 
themselves. Further, if desired, any ofthe data sources may convert its data to a common 
format used by the data collection and distribution system 102 and communicate that 
1 0 converted data to the system 1 02. Ofcourse, the data collection and distribution system 
102 may convert the data sent by the different data sources to any common format or 
protocol and store and organize that data in a database in any desired manner. The data 
collection and distribution system 102 may receive the data from the different data 
sources m a periodic or aperiodic manner, continuously, or intermittently, synchronously 
15 or synchronously, or at any desired time. 

Once received and converted, the data is stored in a database in some accessible 
manner and is made available to applications or users within the asset management suite * 
50. For example, applications related to process control, alarming, device maintenance 
^ag-stics,^ 
3 ^-eandmtegratefted^ 

better than these applications have been able to operate in the past without data from 
vastly different or previously unaccessible data sources. The applications illustrated in 
F,g. 2 as being part of the asset utilization suite 50 may be any of the apphcations 
described in Fig. 1 or can be any other types of applications if so desired. Ofcourse both 
the data sources and the applications which use the collected data illustrated in Fig 2 are 
exemplary in nature and more, less or different data sources and applications may be 
used. L±ew 1S e, the data sources themselves maybe configured to receive datacollected 
bythedatacollectionanddistributionssystem 102. In this manner, different vendors or 
serv.ee probers, who may have proprietary applications, may collect certain data that 
they had not or were incapable of previously acquiring from the data collection and 
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distribution system 102 which may enhance the products or services being offered by 
these service providers. In one embodiment, it is expected that traditional process 
control service providers, who in the past have collected and generated data apart from 
the process control network using typically proprietary applications, will now provide the 
5 collected or generated data to the data collection and distribution system 1 02 which will 
then make that data available to other applications. These other applications can be 
applications executed within computers communicatively connected to the process 
control environment, such as appli cations within host d e vi ces, user interfaces, controllers, 
etc. Additionally, these other applications may be applications provided by or used by 

10 the traditional service organizations. In this manner, any application can now be 
designed to use any data generated within the process control system in any manner, 
whether by applications owned by the process system owners or applications owned and 
managed by service providers. As a result, there are many, many instances in which 
applications can be enhanced because they can use data that was previously unavailable 

15 to them. For example, a corrosion analysis service provider may be able to use data 
collected by a proprietary process control system or proprietary equipment monitoring 
application to enhance the reliability or predictability of the corrosion analysis. Such 
cross pollenation of data from vastly different types of service providers and applications 
was previously unavailable. 

20 Referring now to Fig. 3, a more detailed data flow diagram 200 illustrating data 

flow within the process control plant 10 is provided. Beginning at the left side of the 
diagram 200, data associated with the process plant 10 is collected by or at different 
functional areas or data sources within the plant 10. In particular, process control data 
201 is collected by, for example, typical process control devices such as field devices, 

25 . input/output devices, handheld or remote transmitters, or any other devices which may 
be, for example, communicatively connected to process controllers. Likewise equipment 
monitoring data 202 associated with traditional equipment monitoring activities is 
collected by, for example, sensors, devices, transmitters, or any other devices within the 
plant 10. Process performance data 203 may be collected by the same or other devices 

30 within the plant 1 0. If desired, financial data may be collected by other applications run 
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in computers in the process control plant as part of the performance monitoring data. In 
some instances, the collected data may be from applications or sources outside of the 
traditional process control network, such as applications owned and operated by service 
organizations or venders. Of course the data collected may be any of, but is not limited 
to rotating equipment angular position, velocity, acceleration data <as well as transforms 
of this data to provide power spectral density, frequency amplitude, etc.), equipment 
stress data, strain data, wall thickness data, corrosion extent and rate of corrosion 
progress data, corrosivity of process fluids data, lubrication and wear data, bearing and 
seal data, leakage presence rate and composition of escaping liquids and gasses data 
including but not limited to data about volatile organic and inorganic compounds, bearing 
temperature data, acoustic transducer data, process physical and compositional 
measurernentdata,etc. This data maybe collected many manner including automatically 
ormanually. Thus, data collectors mayinclude hand held collection devices, laboratory 
chemical and physical measurements, fixed or temporary on-line devices, devices which 
periodically (e.g., RF) telemeter data from remote process and equipment measurement 
devices, on-line device inputs or remote multiplexers and/or concentrators or any other 
data collection devices. • 

The process control data, equipment monitoring data and process performance 
data may be reconciled, verified, validated and/or formatted by data collection and 
reconciliation applications 204 (which maybe part of the data collection and distribution 
system 102 of Fig. 2) run within the data collection device or within any other device 
suchasatacentraldatahistorian, P rocess controllers, equipment monitoring applications, 
etc. or any other device which receives or processes this data. Of course, the collected 
data maybe reconciled or massaged in any known or desired manner. For example, the 
data maybeput into a common format or scale, maybe converted to different orstandard 
(common) units, may be scanned for outliers, erroneous orincorrcct data, may be verified 
or validated in any known or desired manner, etc. There are many known methods or 
techniques of performing data reconciliation and method of Teconciling, messaging, 
verifying Or collecting data may be used. Still further, the different types of data maybe 
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collected by a common collector or data collector routines even though this data may be 
in different formats, protocols, etc. 

After being reconciled in any known or desired manner or, in some cases, not 
being reconciled at all, the collected data may be provided to one or more applications 
5 typically associated with the different functional areas of the process control system 10. 
For example, as is known, different process controller or control applications 208 
illustrated in Fig. 3 as part of the process control function block 206 may use the 
collected process control data 201 for a number of reasons or purposes. These process 
control applications may include, for example, traditional DCS, PLC and SCADA 

10 systems, computer control systems, hybrid systems and digital control systems of any 
type now known or developed in the future. Thus, the process controller applications 
208, using any known or desired process control software or techniques, use the process 
control data 201 to monitor and control ongoing process functions. Such applications 
may perform any type of process control, including for example, PID, fuzzy logic, model 

15 predictive, neural network, . etc. process control activities. The process control 
applications 208 may create, generate or pass alarm data or alarm messages to a process 
operator, may detect problems or concerns or perform audits associated with regulatory 
agencies, such as environmental protection agency (EPA) constraints, food and drug 
administration (FDA) constraints, and may perform other known process control 

20 functions which are too numerous to list here. Still further, one or more diagnostic 
applications 210 may use the collected process control data 201 to perform process 
control diagnostics. Such diagnostic applications may include, for example, applications 
which help an operator pinpoint problems within process control loops, instruments, 
actuators, etc., such as that disclosed in U.S. Patent Application Serial No. 09/256,585, 

25 entitled 'Diagnostics in a Process Control System," which was filed February 22, 1 999, 
is assigned to the assignee of the present application, and is hereby expressly incorporated 
by reference herein. The diagnostic applications 210 may also include expert diagnostic 
engines such as that disclosed in U.S. Patent Application Serial No. 09/499,445, entitled 
"Diagnostic Expert in a Process Control System," which was filed February 7, 2000, is 

30 assigned to the assignee of the present application, and is hereby expressly incorporated 
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by referee hcI dn. Of course, A. process magBostic appIication!! 2 10am ^ „,„ fomi 

of any other typical or standard process diagnostic application and are no. limi.ed to 
these specifically meDtioned herein . Stj „ ^ ^ rf ^ 

application* 2,0 can take any fotm and may, for example, indicate faulty or poorly 
performing loops, tactions blocks, areas, unifs, etc. within fte process control system 
may indicate where loops need to be tuned, etc. 

As also indicated in Fig. 3. a process control historian 21 2 may be used to store 
previo Usly coIlected process comrol ^ ot ou(pa(s ^ ^ ^ ^ 

^' 0 ™^PP«-«o n a208.meproce S scon 0 ^. m agnostica P plicationa210oranyo«rer 
desnedprocessdata. Of course, .he pmcess com™, monitoring apphcations 208 and the 
dtagnostic apphcations 2,0ma y useu,e da* stored in the historian 212 in any known or 
destredmatmer. Still furiher.me apphcations 208 and2 10 may use process models 2M 
(winch may be par, of me models 56 of Fig. 1 and par, of a performance moni,orin g 
functional area) which maybe crea,ed ,o model a!I orpar, of meprocess units or areas 
15 within the process 10. 

Still finther, an equipmen, monitoring fimctional block 220 receives me 
• eqummen, condition da* 202 or fte reconci,ed version of such data if reconciliation is 
perfmrned on tha, data. The e q „ip m e„, monitoring functional block 220 includes 
equ,pment or condition monitoring applications 222 winch may. for example, accep, or 
generate a.arms indicating prob.ems with various pieces of equipment de.ee, poorly 
perfomting or faulty equipmen, wimin me plan, 10 or de.ee. othe, equipmen. problems 
orconditionswmchn M ybeofi„,erest.oamain«enanceperson.Eqmpme n ,m„ni«orm^ 

apphcations are wellknown and t^icallybcludeutiUtiesadap.ed.o me different specific 
types of equipmen, wimin a plan,. As such, a detailed discussion of these applications 
- ,sno, necessary. Likewise, equipmen, diagnostic applications^ may be imptanen.ed 
«od.,ec,and diagnose equipmen, Problems based on raw da ta measured pertaining tome 
Such equipmen. diag.os.ie appfications 224 may include, for example 
vbraoon sensor applications, rotating equipment apphcations. power measuremen, 
apphcations. etc. Of course, Acre are many different types of known equipment 
condmon monitoring and diagnostic applications which can pmduce many kinds of 



• 27 



different types of data associated with the state or operating condition of different pieces 
of equipment within a process control plant. Still further, a historian 226 may store raw 
data detected by equipment monitoring deuces, may store data generated by the 
equipment condition monitoring and diagnostic applications 222 and 224 and may 
5 provide data to those applications as needed. Likewise, equipment models 228 (which 
may be part of the models 56 of Fig. 1 and thus part of the performance monitoring 
functional area) may be provided and used by the equipment condition monitoring and 
diagnostic applications 222 and 224 in any desired manner. The creation and use of such 
models is well known in the art and need not be described further herein. 

10 Likewise, a process performance monitoring functional block 230 illustrated in 

Fig. 3 receives process performance data 203 which may or may not be reconciled, 
formatted, etc. by the data collector 204. The process monitoring functional block 230 
includes process performance monitoring applications 231 which may, for example, use 
process control models 214, process equipment models 228 or performance models 232 

15 to perform process performance monitoring in any known or desired manner. Another 
set of applications 233 may use the output of the process performance monitoring to 
make recommendations to user or advise user how to change process equipment 
configuration to perform better overall use of the process or to produce a process which 
operates more efficiently or makes more money. A process performance monitoring 

20 historian 234 may store raw data detected by the process performance monitoring 
devices, may store data generated by the process performance monitoring applications 
231 and the recommendation applications 233 and may provide this data to other 
applications as needed. The creation and use of process models and process performance 
monitoring applications is known and will not be described further herein. 

25 As illustrated in Fig. 3, financial data, in the form of financial constraint data and 

process operation constraint data including, for example, what products must be 
produced, the quality of the produced products, time deadlines, cost and supply 
constraints, pricing and valuation data of products made or sold, etc. maybe collected at 
a functional block 239. Generally speaking, although it is not necessary, the functional 

30 block 239 will include a computer running one or more data input applications that 
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collects process performance data from the models 214, 228 and 232 and financially 
related data from persons associated with theprocess 1 0, such as managers, or from other 
sources. These financial applications may also generate this data. However this 
financial data may come from many other sources instead or in addition to those listed 
» here. 

While the collection and processing of data as described above with respect to 
Fig. 3 is currently being performed in process control plants, generally speaking, the 
collected data, i.e., the process control data, the process monitoring data, and the 
equmment monitoring data is provided to different people, is collected and used in 
Afferent formats and is used by completely different applications for different purposes 
Thus, as explained above, some of this data may be measured or developed by service 
organizations who use applications that are proprietary and not compatible with rest of 
the process control system. Likewise, data collected by or -generated by financial 
apphcations typically used in a process control environment may not be in a format or 
protocol recognizable or useable by process control oralarming applications. As aresult, 
a mamtenanceperson and the equipmen^^ 

a person uses do not typically have access to (and have not be constructed to use) data 
collected by or generated by any of the process control applications, process models or 
financal applications. Likewise, the process control operator and the process control 
momtoring and diagnostic applications used by that person do not generally have access 
to (and have not be constructed to use) data collected by or generated by the equipment 
momtonng applications and performance modeling or financial applications. Similarly 
a busmess person may not have any access to data collected by or generated by either of 
the process control or equipment monitoring applications and, in fact, may have a whole 
Afferent set of data on which* operate and make decisions about the operation of the 
Plant 10. Likewise, much ofthedata measured by or generated in the functional blocks 
206, 220, 230 and 239 is done so by service organizations who use proprietary 
apphcations and who generally do not make much of their data available for other uses 
To overcome the limitation of limited or no access to data from various external 
sources, the data collection and distribution system 102 is provided to collect data, 
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convert that data if necessary into a common format or protocol that can be accessed and 
used by applications within the asset utilization suite 50 illustrated in Fig. 3. In this 
manner, the applications within the asset utilization suite 50 receive the different types 
of data from the different functional areas or data sources including the process control 
5 functional area 206, the equipment monitoring functional area 220 and the performance 
monitoring functional area 230, and integrates this data in any of a number of ways to the 
direct benefit of the operation of the plant 10. The goal of the asset utilization suite 50 
may be to produce a better view of the plant 1 0, enable better understanding of the overall 
condition of the plant 10, and allow better decisions to be made regarding the control or 
10 use of the plant 10 or the assets of the plant 10 based on all of the data in the plant and, 
overall, to run the plant 10 more optimally. The integration of the different types of 
functional data may provide or enable improved personnel safety, higher process and 
equipment uptime, avoidance of catastrophic process and/or equipment failures, greater 
operating availability (uptime) and plant productivity, higher product throughput 
15 stemming from higher availability and the ability to safely and securely run faster and 
closer to design and manufacturing warrantee limits, higher throughput stemming from 
the ability to operate the process at the environmental limits, and improved quality due 
to the elimination or minimization of equipment related process and product variations. 
To the contrary, in the past, the different functional areas, e.g., the process monitoring, 
20 the equipment monitoring and the performance monitoring, were performed 
independently and each tried to "optimize" their associated functional area without regard 
to the effect that given actions might have on the other functional areas. As a result, for 
example, a low priority equipment problem may have been causing a large problem in 
achieving a desired or critical process control performance, but was not being corrected 
25 because it was not considered very important in the context of equipment maintenance. 
With the data collection and distribution system 1 02 providing data to the asset utilization 
suite 50, however, persons can have access to a view of the plant 10 based on two or 
more of equipment monitoring data, process performance data, and process control 
monitoring data. Similarly, diagnostics performed for the plant 1 0 may take into account 
30 data associated with process operation and the equipment operation and provide a better 
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overall diagnostic analysis. Thus, applications within the asset utilization suite 50 may 
use the process control, equipment monitoring and process performance data to make 
better °™°rec°n*letedecisions^ 

area, may optimize the overall plant operation in a way that the independent operation of 
> the different functional areas does not allow. 

While the data collection and distribution system 1 02 can be located between the 
functional data collection or generation sources 206, 220, 230 and 239 and the asset 
utmza.cn suite, it can also or instead be located elsewhere in the system 10 depending 
onwhatthedifferentdatasou^ ^ ^ 

data collection and distribution system 1 02 can be located an^here in the flow diagram 
ofF lg . 3 depending on what the data sources are and which sources are already integrated 
or provide data in a standard or recognizable format. As indicated above, the data 
collects and distribution system 102 may be located between the asset utilization suite 
50 and the functional areas 206, 220, 230 and 239, which will normally be the case 
However, the data collection and distribution system 1 02 may be located in front of any 

or all of me functional areas 206, 220, 230 or 239 or some combination of these two 
Sull further, while the data collection and distribution system 1 02 has been illustrated as - 
bemg centralized, i.e., in one place, it could be spread out and implemented at multiple 
Places m the system 10. Thus components of this data collection and distribution 
software could be executed in multiple different devices in order to be able to collect 
more or better data from disparate data sources. Each of these multiple data collection 
applications could operate to collect data from one or more sources, depending on the 
collection needs and placement of these applications and each application could then 
prov.de the collected and formatted data to one or more centralized databases within the 
system from which this data can be accessed by other applications. ■ 

Referring again to Fig. 3, the asset utilization suite 50 is illustrated as including 
anumberofapplicationswhichusedata collected from different functional areas or data 
sources within the process control plant 10 including, for the sake of illustration the 
performancemonitoringfunct^ ^ 
the equipment monitoring functional area 220. Of course, the asset utilization suite 50 
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may receive any of the data from these areas including the raw data, the reconciled data, 
the data stored in the historians 212, 226 and 234, the data produced by the monitoring 
applications 208 and 222, the data produced by the performance models 232, and the data 
produced bythe diagnostic applications 210 and 224. If desired, the asset utilization suite 
5 50 may also use the process models 214 and the equipment models 228. It will be 
understood that while the asset utilization suite 50 is illustrated as including a specific 
number of applications, the suite 50 could include any number of applications including 
one or more which perform any one or more of the functions described herein. 

In particular, the asset utilization suite 50 illustrated in Fig. 3 may include one or 

10 more integrated plant state monitor applications 240. Such plant state monitor 
applications 240 may include the index generation application 51 of Fig. 1 that creates 
indexes associated with devices, like process control and instrumentation devices, power 
generation devices, rotating equipment, units, areas, etc, and/or associated with process 
control entities, like units, loops, areas, etc. within the plant 10 based on two or more of 

15 process control information and device information and performance information. The 
generation and display of these indexes will be described in more detail later. However, 
generally speaking these indexes maybe based on process control data as well as process 
performance and equipment monitoring data and may be displayed in a consistent format 
to a user via an integrated display. 

20 As illustrated in Fig. 3, the asset utilization suite 50 may include or use an 

integrated display application 244 (which may be any or all of the interface applications 
58 of Fig. 1) that displays different data to any user in an integrated or common manner. 
Generally speaking, the display application 244 is configured to provide different 
information to any user, wherein the displayed information reflects or is based on two or 

25 more of the process control data 20 1 , the equipment monitoring data 202 and the process 
performance data 203. The application 244 receives inputs from other applications 
within the suite 50 and may enable a user to view the raw data 201, 202 and 203, may 
enable a user to go from screen to screen to view different parts or aspects of the plant 
10 based on the raw data or processed data, may enable a user to view processed data, 

30 such as data generated by the equipment condition, process monitoring or performance 
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monitoring applications 222, 208 and 231 the process models 214, the equipment or 
process diagnostic applications 224 and 210, or data generated by other applications 
within the asset utilization suite 50. 

The asset utilization suite 50 may also include an integrated alarming application 
246 which may receive both process and device alarms and may display these alarms in 
a consistent format to a user. Such an integrated alarm display application is disclosed 
in U.S. Patent Application Serial Number 09/707,580, entitled "Integrated Alarm Display 
in a Process Control Network," which was filed November 7, 2000, is assigned to the 
assignee of this application and which is expressly incorporated by reference herein. The 
integrated alarm application 246 may produce user displays 248 which provide 
iruormation on the received alarms, provide an alarm banner integrating the alarms,etc. 

The asset utilization suite 50 may also include one or more integrated diagnostic 
applications 250 which integrate the process control data 201, the process performance 
data 205 and the equipment condition data 202 to perform diagnostics on a plant wide 
basis. For example, there are many instances when process equipment data and process 
control data can be combined to produce a better diagnostic analysis about a condition 
within the plant 1 0 than the use of just one of those types of data. Likewise, the output 
of an equipment condition diagnostic application 224 and the output of a process control 
diagnostic application 210 can be combined to produce a more complete diagnostic 
analysis for a process plant than the output of either of the individual applications. The 
integrated diagnostic applications 250 may include expert engines of any desired types, 
process and/or equipment models and predictive applications that make predictions about 
conditions in theplant lObased on data received or other diagnostic decisions made from 
other applications. Of course, the integrated diagnostic application 250 may provide a 
user display via the interface application 244 to indicate different diagnostic analyses. 
Further, the integrated diagnostic application 250 may enable a user to configure the 
application 250 to thereby create specific integrated diagnostic determinations. For 
example, a user may be presented a configuration screen in which the user selects 
different diagnostic applications to be performed (including for example, both process 
diagnostic applications 210 and equipment monitoring applications 224) and may then 
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combine or make other diagnostic decisions based on the outputs of these selected 
diagnostic applications. In this case, the user may connect the outputs of certain known 
process and equipment monitoring or diagnostic applications to a new function (which 
maybe, for example, a process performance function) which combines or evaluates these 
outputs in some way to make a diagnostic determination. Alternatively, a new diagnostic 
application using both process control data 201 and equipment monitoring data 202 may 
be created to perform plant diagnostics. In these examples, the diagnostic application 250 
may output to a user display via, for example, the user interface application 244. 

The fault diagnostic applications 250 may also include a backtracking application 
that uses both process control data 201 and equipment condition data 202 to determine 
the source of a detected problem. Backtracking applications which try to locate sources 
of detected problems based on either process control data or equipment conditioning data 
exist, but no such backtracking application has been used to pinpoint the problems in a 
plant based on both process control data and equipment conditioning data. The use of 
a backtracking application using both process and equipment data may provide a better 
or more complete answer as to the cause of a problem or condition within the process 
plant 10 than previous backtracking applications that use only one of process or 
equipment data. Of course, these backtracking applications integrate process control and 
equipment monitoring data and, if desired, process performance data to determine a cause 
of a problem. Such a cause may be a combination of factors that may be weighted 
differently, a detection of process and equipment conditions that should not exist 
simultaneously (such as a pump running and a shutoff valve closed), etc. The 
presentation of these problems may be in tenms of probabilities, weighting, predicate 
condition states, etc. These backtracking or other diagnostic applications may use formal 
models of the process and equipment, as well as the derivatives of the input and output 
variables and actual measurements of these variables to compute the total derivative of 
the output variables with respect to the input variables and evaluate this total derivative 
vising real process measurements to compute the causal contributions of different 
potential sources. The causal data may also be verified, validated and reconciled with the 
actual output data from the plant 10 to determine how well the predictions held out 
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In any event, one or more other action applications 260 may be provided to take 
some action with respect to diagnostic decisions made by the integrated diagnostic 
application 250 or in response to alarms or other conditions. For example, the 
application 260 may provide a list of potential actions or recommendations to a user via 
the user interface application 244, or to a predictive application 262 which may predict 
the result of such recommendations and display such results to a user via the integrated 
display application 244. These recommendations may, for example, be designed to take 
actions to correct a problem, to get longer life out of the plant 10, to run the plant 10 
more economically or within set financial or EPA constraints, to avoid future problems 
based on current or predicted process and equipment functionality, etc. The application 
2 60 may also enable the user to run simulations of the plant 1 0 based on proposed actions 
to see the simulated effect of these applications prior to implementing the action. The 
application 260 may take actions to collect more or better data in the act of making a 
better diagnostic decision. This data collection may entail automatically causing the 
equipment condition monitoring or the process monitoring applications or the 
performance monitoring applications to collect more or different types of data. 

The application 260 may also, if so configured, automatically take actions within 
the plant 1 0, such as resetting set points, tuning loops, reconfiguring equipment, etc. as 
indicated by the feedback path 264 based on the diagnostic decisions made by the 
apptication250, alarms, etc. These actions may or may not involve using process control 
applications, equipment monitoring and control applications to implement changes to the 
system. These actions may also entail reconfiguring the plant 10 to make a different or 
more of one type of product over another or to otherwise reconfigure the plant 10 to 
maximize financial gains or effect other concerns. Still further, the application 260 may 
call other applications, such as an automatic work order generation application 270 
(whichmay be the application 54 of Fig. 1) to order parts needed for equipment, toorder 
raw materials needed to produce new products, etc. Of course, the application 260 may, 
use integrated alarming, financial constraints or directives or other data to take emergency 
actions, to perform control to cause automatic or manual changes to be made to the plant 
1 0 to effect directives etc. as necessary. 
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As will be understood, the user interface 244 can display any or all of a number 
of different types of user screens based on the application within the suite 50 being 
executed. Thus, for example, the user interface 244 may display equipment performance 
screens, raw data screens, sates diagrams 242, etc. The user interface 244 may also 
5 display integrated alarm screens 248 produced by the integrated alarm application 246. 
Similarly, diagnostic displays 273, recommendation screens 274, and screens indicating 
target production and equipment utilization 275 and 276 may be created by any of the 
fault diagnostics applications 250. Likewise, production planning and financial screens 
277 of any nature maybe created by the action taking applications 260. Of course, other 

10 types of screens and displays may be created by these and other applications based on 
data from numerous data sources. 

It will be noted that, while Fig. 3 illustrates the process control, the equipment 
monitoring and diagnostic, and the performance monitoring applications as being 
separate from the suite of applications 50, these specific applications could be part of or 

15 used by the suite of integration applications 50 if so desired. Further, while Fig. 3 
illustrates data associated with one embodiment of a plant 1 0, Fig. 3 is not meant to 
indicate physical locations of any of the applications within the suite of applications 50. 
Thus, any and all of the applications and hardware illustrated in Fig. 3 can be located at 
any desired places within the plant (or even away from the plant 10 if so desired) and 

20 these applications need not be located in the same place. Still further, the flow of data 
between data collectors and the data collection and distribution system 102 as well as 
between the data collection and distribution system 102 and the applications illustrated 
in Fig. 3 may occur over any desired network, such as a LAN or WAN, the Internet, any 
Intranet, etc. Data may be transported in any desired manner using any desired hardware 

25 including, for example, any physical medium, any dedicated or shared information 
transport method including without limit the use of wired, wireless, coaxial cable, 
telephone modem, fiber otic, optical, meteor burst, satellite, etc. devices. This 
communication may also use any desired protocol including without limit, Fieldbus, 
XML, TCP/IP, IEEE 802.3, blue tooth, X.25, X.400, protocols or any other protocol now 

30 known or developed in the future. 
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Moreover, the data maybe conditioned or compressed in any stage of being sent 
to, used by or sent from the integration applications 50. Of course, any known or desired 
compression may be used including, for example, wavelet signal representation, Fourier, 
Hadamard, etc. transformation,, communication of Fourier etc. coefficients, exception' 
5 processing, swinging door data compression, etc. 

Still further, the integration applications 50 such as the diagnostic application 250 
nay use any joint models of process equipment and behavior to make diagnostic or 
predictive decisions including, for example, fonnal mathematical models, statistical 
correlations, Kalman filter based estimators, neural networks, fuzzy logic based models 
10 or any combination of these or other models. 

In one embodiment, the diagnostic application 250 may enable a user to view*he 
characteristics of the waveforms of process or condition monitoring sensor outputs and 
trend and/or alarm and/or invoke control changes when these patterns change. This 
functionality can be implemented by pattern recognition with alarm bounds onthefeature 
set, or by looking at the Fourier components and providing trending and/or alarming 
and/or control initiation based on limits set on the individual Fourier coefficients or a 
weighted combination of the Fourier coefficients or some function thereof (e.g. the 
square, total AC power, the PSD coefficients etc.) 

In one embodiment, one or more cards, such as input/output (I/O) cardseonnected 
to one or more of the process controllers 12 or 14 of Fig 1 may be provided to collect, 
convert and process or buffer condition monitoring inputs from process and equipment 
monitoring activities and thus, these cards may implement part or all of the data 
collection and distribution system 1 02. These I/O cards (which may be subassembly 
processors having data collection routines implemented thereon) may perform data 
collection activities for some or all of the devices, areas, etc. of the process plant 10 to 
provide the data needed by the integrated applications within the plant 10. These cards 
maybe configured to collect any or all of the process control data, equipment monitoring 
data or process performance data from various and multiple and different device types 
or sources within the process control system. Again, such data sources may include, fr>r 
example, hand held collection devices, laboratory chemical and physical measurement 
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sources, direct on-line input sources and remote sources. Still farther, another card, such 
as an I/O card connected to a controller may be provided to store and implement the one 
or more of the integrated applications described herein. Thus, while Fig. 1 illustrates the 
data collection and distribution applications, as well as the integrated applications within 
the asset utilization suit being implemented in a centralized computer 30, these 
applications, and the data collection activities for these applications maybe implemented 
in one or more dedicated cards or other devices distributed throughout the process plant 
1 0. These cards or subassembly processors could be connected directly to a user interface 
and controller via a system bus such as the bus 32 of Fig. 1 or could be part of an 
input/output system associated with one or more of the controllers, or could be located 
elsewhere. Of course, one such dedicated card could run all of the integrated applications 
or any subset thereof depending on the configuration and nature of the process plant 10 
in which it is being used. In some cases, some preprocessing of data collected at the 
controller level may be performed and this preprocessed or partially processed data may 
then be provided to another device, such as the computer system 30, which may complete 
the integrated processing. In this manner, the integrated applications 50 may be 
distributed in nature when implemented within a plant environment. 

One method of collecting and integrating data from disparate data sources will 
now be discussed with reference to Figs. 4-6. In this example, it will be understood the 
data collected from disparate sources of data is converted into a format being used by the 
process control system which is implemented using the DeltaV process control system 
sold by Fisher Rosemount Systems, Inc. As a result, the process control data is not a 
remote data source. However, other data, such as maintenance data, performance 
monitoring data, process model data, financial data, etc. is from external data sources. 
Generally speaking, this system is configured using a configuration system that stores 
data about and tracks the configuration of the system. In the past, such a configuration 
system was limited to the placement and interaction of process control devices, software 
and strategies and, to a limited extent, included maintenance information about certain 
devices such as field devices. However, because the main focus of the system was to 
cater to process control operators, the information displayed to the user and tracked by 
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the configuration system was generally limited to process control data. In this known 
system, a configuration data base stored, and an explorer application displayed 
information pertaining to the process control devices and the data collected by and 
generated by these devices. 

Generally, in order to enable data from different data sources to be collected and 
used in a single system, a configuration database or other integrated configuration system 
is now provided to enable different data sources to provide data to the system for use as 
a single data source. Such a configuration database is used to collect and store data from 
other, disparate sources of data and an explorer-type display or hierarchy is provided to 
allow the mampulation, organization and use the collected data to thereby make that data 
available to different applications. 

Fig. 4 illustrates an architectural overview of a system 300 which implements the 
collection of data from disparate data sources with a process control system. Generally, 
the system 300 includes an information technology systems (ITS) section 302 which may 
include amaintenance management system 304, a product inventory control system 306, 
a production scheduling system 308, as well as other systems connected by a LAN, the 
Internet, etc. The ITS 302 is connected to a web services section 310 via an XML • 
transactionserver312. The server 3 12 sendsXML wrapped data to the web services 310 
indicative of the data used by or generated by the blocks 304, 306, and 308. 

The web services 310 includes a series of web service listeners 314 which listen 
for or which subscribe to certain data from other data sources and provide this data to the 
subscribing applications. The subscribing applications may be associated with the 
applications within the ITS 302 or a process control system. The web listening services 
(which may be part of the data collection and distribution system 1 02) may listen for and 
redistribute alarms and events data, process condition monitoring data and equipment : 
condition monitoring data. Interfaces for this data are used to convert the data to a * 
standard format or protocol, such as the Fieldbus or DeltaV protocol or to XML as 
desired. 

The web services 3 1 0 are in contact with and receive data from other external data 
sources via web servers 3 1 6. These external sources may include vibration monitoring 
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data sources, real-time optimization data sources, expert system analysis data sources, 
predictive maintenance data sources, loop monitoring data sources or other data sources. 
Of course, each source may be connected via a different external server or the two or 
more of the data sources may share servers where possible. Likewise, these data sources 

5 may be embedded in the process control environment or may be separate from it and 
connected to the external servers via the Internet or other LAN or WAN. In any event, 
the web servers 316 may implement some of the functionality of the data collection and 
distribution system 102 by formatting the received data, if desired. 

A process control runtime system 3 1 8 is in contact with the web services 3 1 0 and 

10 the external servers 3 1 6. The runtime system 3 1 8 includes control applications, operator 
interface applications, alarms and events applications and real-time data applications any 
of which can use the data from the external servers or from the web services (and thus 
from the ITS 302). An Interop system 320 is provided to organize and collect the data 
from the web servers 3 1 6 and web services 3 1 0 to make this data available in a common 

15 or consistent format useable by the process control runtime system 318. The Interop 
system 320 may include conversion interfaces such as ROC, OPC, PI and Virtual 
Controller DLL I/F interfaces which can perform data conversion and recognition on the 
data received from the web servers 316 and the web service listeners 314. 

Finally, a configuration database 322 is used to store and organize the data from 

20 the Interop system 320 and the process control runtime system 318, including any data 
from the remote data sources, such as from the external web servers 3 1 6 and the ITS 302. 
Of course, the ITS 302 may also subscribe to and get data from the process control 
system and the remote data sources via the web services 310. 

Fig. 5 illustrates an exampl e display 350 generated by an explorer-type navigation 

25 tool which may be used to store, organize and access the data collected by the data 
collection and distribution system 102 as stored in the configuration database 322. The 
display or hierarchy 350 includes numerous different sections which can be used for 
different purposes. However, the hierarchy 350 represents an organization of, illustrates 
an overview of and provides access to the data or other elements available to the system. 

30 Thus, the hierarchy 350 is used to represent the data stored in the configuration database 
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as well as to manipulate that data so as to change the configuration of the system in some 
manner. As can be seen, the example hierarchy of Fig. 4 includes a number of different 
sections including a "library" section, a "control strategies" section and a "network- 
section, each of which can be used for different purposes or to represent different data or 
different organizations of the data stored in or available to the configuration database. 

Generally speaking the library section includes lists of and provides access to 
different elements stored in or associated with the configuration. These elements may 
be hardware or software elements including, for example, template software modules, 
field devices, controllers, workstations, etc. To represent, organize and provide access 
to data from disparate data sources, the library may also include one or more extemal 
servers which will be used as data flow conduits from the disparate data sources to the 
integrated system. These servers are illustrated in Fig. 4 as the web servers31 6. As used 
herein, the integrated system includes all of the hardware and software elements above 
the data collection and distribution system 1 02 of Fig. 2. Put another way, the integrated 
system includes the elements that use the same data format within the system 10. 

Beneath each external server and, therefore, associated with it, are defined 
elements or parameters of the data source using that server as a conduit of data. The 
defined parameters of the server and, therefore, the data source, may be icons 
representing applications or hardware devices connected to or stored in the server. These 
defined parameters may be populated by XML scripts provided by the actual external 
servers and associated with the different data sources. In some cases, the owners or 
persons who created the data sources, such as service providers or application creators 
may provide the XML scripts defining the operational capability of the servers or data 
sources associated therewith. Conversely, a user or an operator within the integrated 
system may populate the library with the information defining the purpose and attributes 
of the external server. 

An example data source illustrated as being associated with an extemal server in 
Fig. 4 is the RTO+ application. Generally speaking, the RTO+ application is an 
optimization application provided and generally implemented by a process control system 
service provider. This application is usually tailored to a particular process control 
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system and uses models to model the process control plant for the purpose of optimizing 
the control of the plant. Under the RTO+ icon, which is physically located on the data 
source side of the external server, the RTO+ application is illustrated as being concerned 
with a boiler steam turbine. The RTO+ application provides such information as 
5 efficiency of that turbine, the power output by that turbine, and other parameters or data 
measured by or generated by the RTO+ software regarding the turbine. Further, other 
elements related to the boiler steam turbine, as provided by the RTO+ software, are 
illustrated in the library. For example, function blocks defined for or associated with the 
turbine or listed here as well as parameters of those functions blocks. Likewise, alarms 

10 associated with the turbine are illustrated and may be enabled (turned on) or disabled 
(turned off) here. Likewise, an indication of whether other applications, such as 
diagnostic applications, which may need to collect data from the turbine via the RTO+ 
software, are enabled or disabled. Still further, other predefined history data collections, 
which define data to be collected and stored about the turbine, is listed in this section of 

15 the library. It is to be noted that the alarms and other services such as the diagnostic 
services are not actually parts of the boiler steam turbine. However, they are listed in the 
library under this element because they acquire data from the turbine and therefore 
support the turbine. 

Referring now to the control strategies portion of the hierarchy 350, the control 
20 strategies are organized by, for example, geographical areas such as Area 1, Area2, etc. 
Each area may be broken down into different units such as Unitl, Unit2, etc. Still 
further, each unit then can have numerous modules associated therewith. These modules 
may be any modules, such as modules developed within the process control network in 
the consistent format or modules associated with disparate data sources. These modules 
25 are generally used to configure how different applications operate in conjunction with 
each other and communicate with each other. This functionality will be described in 
more detail with respect to Fig. 6. 

The control strategies section illustrates information, as stored in the 
configuration database, regarding the current configuration of the system 10, including 
30 the location and interaction of different hardware in the system 1 0, the location and 
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interacts of different software events within the system 10,etc. An operator or user 
canmanipuJatetheconiiguration of the system by inanipuJating the elements within the 
display 350. For example, to download a piece of software into a hardware device the 
user may drag and drop an icon representing that software onto the hardware element 
5 Placing a new device icon into the hierarchy 350 reflects a new device being physically 
added to the system. 

Generally speaking, the configuration database is designed to store and allow 
mampulationofmemodulesillu^ Otherelements 
eather hardware or software elements, may be represented by a single module or by a 
10 combination of interconnected modules. Thus, when a user is manipulating the icons 
w )t htn the display 350, that user is actually manipulating modules within the 
configuration database or other databases or memories in which these modules are 
located. 

To enable the collection and use of data from different data sources, the display 
15 or hierarchy 350 represents the different data sources as modules or combination of 
modules. Such modules can then be placed in the configuration hierarchy and can be 
manipulated in the same manner that modules associated with entities within the 
integrated system, such as process control modules, are manipulated in the configuration 
database. When creating a module for a previously unknown or unconnected data source 
0 the user defines the type, nature or meaning of data to be received from that data source 
in the context of a module: Using this information construct, the data actually received 
from that data source can then be categorized, labeled, recognized and used within the 
integrated system in the same manner as data from other modules of elements within the 
integrated system. In this manner, any type of data that is received from a disparate data 
source can be collected and stored, even if an organization or person completely 
unassociatedwiththeintegrated system has created the application or device that actually 
generates the data. Of course it will be understood that the data from the data source is 
communicated to the configuration database after being converted by a data conversion 
t -^-,suchasOPC,PI,Fieldbus,etc.Asmdicatedabove.^ 
by the data collection a*d distribution system 1 02, not actually shown in the hierarchy 
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350 of Fig. 5. A more detailed description of a modules for the steam turbine is provided 
with respect to Fig. 6. 

The network section of the hierarchy 350 illustrates the physical and operational 
interconnections of the network. Of course, there will generally be many different types 
of devices and elements associated with the network. However, one illustrated element 
is an ACN (Area Control Node) which includes a controller node. The controller node, 
in turn, has control strategies, such as control and communication software stored therein. 
The ACN also includes one or more input/output (I/O) devices which may be Fieldbus 
I/O devices, HART I/O devices, etc. Of course each I/O device may have different ports, 
devices, function blocks, etc. connected thereto or communicatively tied to the I/O 
device. One or more workstations may also be associated with the ACN. These 
workstations may be user interfaces or other types of workstations. The workstation 
illustrated in Fig. 5 supports or implements numerous applications or other functional 
elements including, in this example, alarms and alerts processing or display applications 
and control strategy appli cations, such as those which are used to configure the controller, 
field devices, etc., to get information about the controller and field devices. 

To enable the collection of data from different or disparate data sources, an 
Interoperation (IOP) section is also provided or executed by this workstation. The IOP 
section (which is also illustrated in Fig. 4) includes one or more of the external servers 
identified in library section of the hierarchy 350. Here, the RTO+ external server (called 
external server 1) is supported by the workstation illustrated in the ACN. Of course, 
other external servers associated with other data sources such as those described with 
respect to Figures 2 and 3 may be provided in this workstation, in other workstations in 
this ACN or in other ACNs, as desired. Any reasonable number of devices may be 
supported by the external server. While all of these devices may be associated with the 
RTO+ application or service, not all devices supported by a server need to be associated 
with one particular data source. In this manner, a single server can support many 
different data sources. 

In this example, one of devices being supported by the external server 1 is the 
boiler steam turbine discussed previously. As similarly indicated in the library section, 
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the boiler steam turbine may include properties, such as efficiency, power, etc., function 
blocks, alarms, etc. ^*^*A*m* U y*ctiaa.te^ nvea rt^to*^ 
or enable alarms such as device alarms in this location of the hierarchy by selecting the 
alarm of the turbine device and enabling it here. Still further, the user can access the 
alarms, properties (such as efficiency and power), function blocks and parameter data in 
this location of the hierarchy 350. 

In this manner, using the IOP section of the hierarchy 350, a user can define and 
then provide access to data from devices, applications, etc. associated with data sources 
thatwerepreWouslyunconnectedtotheintegrateds^tem. In some cases, the user will 
define one ormore modules for the external datasources, such as for external devices or 
applications, and uses these modules to organize and make the data collected from the 
disparate data sources available to other applications. As part of this process, the user 
may device function blocks, parameters, alarms, etc. associated with the external data 
sources. This is the case even though the modules or function blocks for the external data 
sources do not actually exist within the external data sources but are, instead, located 
witfam thedata collection and distribution system 102 as implemented by the workstation 
and external server connected to that external data source. 

Using the configuration hierarchy 350 of Fig. 5, the user defines or imports 
modules associated wim data sou,^^ 

external servers supported by the IOP services. Fig. 6 illustrates aconfiguration screen 
presented by a configuration application which enables modules to be created and 
mampulated so as to be connected tooted Using 
th,s configuration screen, modules for applications and devices within the integrated 
system and modules for applications and devices outside of the integrated system i e 
associated with the disparate data sources, can be connected together so is to 
commumcate with one another. This connectedness then defines the data flow between 
modules and, thus, the data flow between external data sources and applications within 
the integrated system or vice versa. 

Modules may be created by dragging one of a plurality of module templates 360 
(on the left side of the screen of Fig. 6) and placing the selected template into the 
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configuration screen 362 . The module may then be assigned to a particular device or 
data source, such as the turbine device within the IOP services or within the library of the 
hierarchy of Fig. 5 using pop up properties boxes and the like. Once connected with a 
particular external device or data source via an IOP service and external server, the 
5 module may be defined to include certain parameters associated with that device. Such 
parameters may be properties of the module that are available from the module such as, 
by way of example, outputs from the module. Some or all of the defined module 
parameter data may be reflected as associated with the external device or data source in 
the hierarchy 350 of Fig. 5. 

10 In this case, a steam turbine module 364 includes an efficiency parameter 366 and 

a power parameter 368 which are available as outputs from the module. The other 
elements of the module 364 reflected in the hierarchy 350 of Fig. 5 are also provided as 
part of the module including the function blocks, the device inputs and outputs, alarms 
associated with the device, etc. The turbine module 364 associated with or created for 

15 the boiler steam turbine of the hierarchy 350 of Fig. 5 also includes alarms, which are the 
alarms identified by or enabled by the user in the IOP or library sections of the hierarchy 
350. One of these alarms is available as an output. The outputs of the module are (data 
associated with the turbine device that are provided through the external server from the 
device itself or other software associated with the device. These outputs may be 

20 parameters, measured values, etc. depending on how the module 364 is defined. The 
inputs to the module are inputs from applications etc. which may be sent through the 
external server to the actual device or software associated with that device to effect that 
device in some manner. In effect, the inputs of the module 364 are data or control signals 
that the associated device will accept or recognize. The function of these inputs will be 

25 defined by the device or software associated with the device. These inputs enable data 
from other modules, such as modules within the integrated system or modules associated 
with other external data sources to be sent to the external data source or device through 
the IOP services and thus through the external server connected to the external data 
source. The external data source may use this input data in any manner it desires. It may, 

30 for example, be controlled by this input data, or use this input data to make better or more 
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accurate calculations about the parameters of the device, etc. If desired, the modufes for 
the external data sources may also include software which use the inputs, outputs, 
parameters, etc. to make calculations of some nature. 

In the preferred embodiment of the configuration system, the modulescreated for 
! the devices, applications, etc. within the integrated system and the external data sources 
are based on the Fieldbus or DeltaV module concept, which are very similar. Here, the 
module 364, because it is associated with an external data source which does not use the 
module organization, is a shadow function block or shadow module. Generally speaking, 
a shadow function block or shadow module element is a function block or module in the 
configuration database of the integrated system and is configured to be useable as a 
module. ™^hadowmodule,however,ismcontactwimmedatasourceordeviceand 
has its outputs generated by or provided by that external device. Furthermore, the 
shadow module provides the inputs it receives to the external data source. Thus, the 
shadow module merely has inputs and outputs and a state that reflects the inputs to 
outputs of and the state of the actual device or data source as determined by the data 
received from that data source. The use of a shadow module, however, makes the inputs 
and outputs of the external device or data source accessible to the other modules within 
the integrated system, such as modules associated with applications in the asset 
utilization suite 50. In this manner, the shadow function block or module operates as a 
conduit of information between the external data source and the applications within the 
integrated system by putting the data received from the external data source in a format 
that is usable by other applications within the integrated system. The description and use 
of shadow function blocks is described in U.S. Patent Application Serial No. 09/15 1 084 
entitled "A Shadow Function Block Interface For Use in a Process Control Network" 
which was filed on September 1 0, 1 998, which is assigned*, the assigheeof the present 
apphcation and which is hereby incorporated by a reference herein. 

The configuration screen 362 of Fig. 6 illustrates that the user has^onfrgured the 
turbine module 364 to provide outputs thereof to inputs of another module which is 
^entitled as a calculation or Calc module 370. The Cale module 370 includes a power 
inputreceived from the turbine module 364 and au input received from a PED module 372 
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which may be a module associated with a process control routine within the integrated 
system. The Calc module 370 uses these inputs to create an output which may be 
indicative of a need to change some parameter within the turbine associated with the 
module 364. In this example, the output of the Calc module 370 is provided to an input 
5 of the turbine module 364 so that this data is sent, via the lOP services and the external 
server, to the applicati on (such as the RTO+ application) that provides the data associated 
with the turbine. It will be understood that the Calc module 370 is a module which is 
implemented in and run in a workstation within the integrated system. The Calc module 
370 maybe associated with another application, such as one of the applications with the 

10 asset utilization suite 50. As such, the configuration screen 362 of Fig. 6 illustrates the 
manner in which one external data source is coupled to an application within the 
integrated system to provide data to that application. Still further, the application within 
the integrated system (i.e., the Calc module 360) uses the remote data and process control 
data to perform a calculation and sends other data or information to the external data 

15 source via an external server. It will be understood that the external server is configured 
to use OPC or any other desired communication conversion protocol to convert the data 
to the proper format when flowing in either direction between the integrated system and 
the external data source. 

While a configuration or communication strategy between an external data source 

20 and an application within the integrated system is illustrated in Fig. 6, it will be 
understood that modules for other data sources, different modules associated with the 
same data source, etc. could be created as well and interconnected to provide 
communication between any external data sources and any applications within the 
integrated system. Still further, modules from different external data sources could be 

25 communicatively coupled together to provide communication between these data sources. 
In this case, the data collection and distribution system 102 provides the necessary data 
collection and conversion between the data formats associated with the different external 
data sources. 

One example of manipulation of data from an external data source within a 
30 module created to collect and organization data from that source is the use or creation of 
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alarms for an external data source. In particular, alarms can be denned for a module to 
collect and reflect actual alarm data provided from the external source. Additionally or 
alternatively, alarms can be created within a module based on data received from the 
external data source associated with thatmodule. In the case in which alarms are created 
► wnJnnthemoduJe,a Wion block within the module can acquire data from the external 
source as well as data from other sources if so desired and perform any desired 
computation to determine if an alarm or alert condition exists. If so, this function block 
mayset an alarm signal that will be associated with the module and that can be monitored 
by or sent to alarming applications which process this alarm in the same manner as other 
alarms are processed. Such alarm processing could include displaying the alarm to the 
user, stonng the alarm, enabling the alarm to be acknowledged, -etc. Furthermore, the 
alarm capability of a module, such as a module associated with an external datasource 
can be enabled or disabled (which may turn the alarm capabilities of the module on or 
off) v» the hierarchy 350 of Fig. 5. Thus, it will be understood that data from external 
data sources can be mapped to an alarm within the module or can be used to generate , 
alann for the module and, thus, for the external data source. 

To access, acquire or view data from an external data or associated with _ 
external data source, a user may go through library section of the hierarchy 350 to view 
themformation associated with theextemal servers. Additionally, the user may view the 
control strategies and look for the particular module for the external data source Still 
further, theuser may use the ACN, workstation, IOP, external server, device pam within 
the hierarchy 350 to find the appropriate data. 

Similar to the alann services, other types of services for the external data souroes 
such as diagnostic services, may be provided for the external data sources using the 
"erarchySSOofFig^andthedata collection and distribution system 102. For example 
some diagnostic applications regularly collect data from or about males' within the 
-tegrated system and use this data to diagnose problems, poor performance, etc. The 
same diagnostic applications can now be used to collect data about external data sources 
usmg the modules created for that data source. Thus, the data needed by the diagnostic 
apphcation can be collected in an automatic manner as long as the module associated 
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with the external data source is configured to receive or collect the data needed for the 
diagnostic application from the external data source. In some cases, the information 
about the module itself, such as variability within inputs, outputs or other parameters of 
the module may be used for diagnostic purposes. Of course, any desired data may be 
5 collected or used for these diagnostic applications. Similar to alarms, the diagnostic 
applications, such as the Inspect application sold by Fisher-Rosemount Systems, Inc. may 
be enabled or disabled in the hierarchy 350 of Fig. 5. This diagnostic application is 
described in detail in U.S. Patent Application Serial No. 09/256,585 entitled "Diagnostics 
in a Process Control System.'' Of course, other diagnostic applications could create 

10 indexes for the external data source to indicate a health of that data source or device 
associated with the data source. Such indexes might include a utilization index, a 
performance index, a variability index or other help index. 

Using a common module definition or scheme within the data collection and 
distribution system 102 makes the creation and use of this system more easily understood, 

15 programmed and used. Thus, it maybe desirable, although it is not necessary, to use an 
open or well known module protocol, such as the Fieldbus protocol, the DeltaV protocol, 
which is very similar to the Fieldbus protocol or other open protocol to create and 
manipulate the modules described herein. When using such and open protocol, service 
providers who may be supplying or overseeing the external data sources may be able to 

20 support the data collection and distribution system 102 by creating a front end for the 
external system that uses the open protocol to communicate data to the data collection 
and distribution system 102. If this is the case, an OPC, PI, etc. front end for the data 
collection and distribution system 1 02 may not be necessary for that data source. Instead, 
the modules created by the data collection and distribution system 102 may simply be 

25 imported from the remote data sources themselves. Furthermore, the provision of this 
front end on the external data sources enables the operators or owners of these data 
sources to define the data available from their system, to provide alarms and alerts that 
are most pertinent to their system, to better support diagnostic applications used within 
the integrated system, etc., all of which makes their products or services more desirable. 

30 Likewise, this front end makes it easier for their applications to acquire and use data from 
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other sources, such as other external data sources and applications within the integrated 
system, which may add value to their product 

While the data collection and dmrib ution ^ lcm has ^ descrfbe M ^ 
usmg modu.es and being organized and .nan.pu.ated ming m ^ 
such as that of Fig. 5, it will be understood that this is only one way to implement this 
system. Any other manner of collecting the data fion, external data soumes, convening 
« to a common or usable format, storing ma, data and providing me dau <o other 
applications could be used as well. Furthermore, whi,e the dau collection and 
drsmhution system 102ofFi g . 3 hasbeeniI ) ns 0 a,odasbeingas i ng k entiry, i.cnuldbe 
drsmbuted in natum. Thus, different workstations or other computer devices sptead 
throughout an integrated system may col.ec, dau, from different sources and process and 
store thrs data in a manner ihat makes i, available to the integrated system 

^ medate ~»«tiouanddismbntionsy S ,em I 02 i scon„g„«d,merea re m a ny 
Afferent types of applications which can use the data collected fiom disparate data 
sources to perform new or more complete functions within a process environment For 
exampte, one ormomofthe apphcations within the asset utilization suite 50 maybeused 
- to execute or oversee me execution of one or mo« mathematics, or software models tha, 
model the operation of a partial pkm, or entities within the plan,, such as devices 
■nuts, loops, areas, en. Thus, process or device mode.s may be created and implemented' 
to use me ejected dau. These models may be based on process. equipmen, or process 
regrons. In one embodiment ,o generate these models, a modeling expert divides me 
plan,,n,o componen, equipmen, and provides, mode, for, he different componen.parts 
a, any desired .eve, of abs,rectio». Forexample, me mode, for a p.an, is imp.emen,ed 
rn software and is made up of or may inch.de a se, of hieramhieaUy related, 
mtercdnnected models forme differen, areas of me plant S imilar.y, me mode, for any 
Plan, area may be made up of individua, models for me differen, unite wimin me plan, 
wrmmterco-mecuonsbetweentheinputsand outputs of mese unite. Likewise, units may 
bemadeup of interconnected equ,pmen,mode,s, and soon. Of course, area models m~ 
have device mode.s interconnected win, mri, mo de,s. ,oop mode,s,«c. Jn mis example 
mode, hierarchy, me inputs and omputs of mode.s for me ,ower .eve. entities, such as 
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devices, may be interconnected to produce models for higher level entities, such as units, 
the inputs and outputs of which maybe interconnected to create still higher level models, 
such as area models, and so on. The way in which the different models are combined or 
interconnected will, of course depend on the plant being modeled. Of course, these 
5 models may receive needed data from external data sources in the manner described 
above. 

An example use of hierarchical software models will now be described with 
respect to Figs. 7A and 7B. Fig. 7A illustrates models for multiple areas 380, 381 and 
382 within a refining plant. As illustrated in Fig. 7 A, the area model 382 includes a 

10 component model of a raw material source 384 which feeds raw material such as crude 
oil to a pre-processor model 388. The pre-processor 388 provides some refining to the 
raw material and provides an output, typically crude oil to a distillation process 390 for 
further refining. The distillation process 390 outputs CjH,, usually a desired product, and 
QHfi which, generally speaking, is a waste product. The QHe is fed back to a C 2 cracker 

15 392 which provides its output to the pre-processor 388 for further processing. The 
feedback from the distillation process 390 through the Cj cracker 392 is a recycling 
process. - Thus, the model for the area 382 may include separate models for the raw 
material source 3 84, the pre-processor 3 88, the distillation process 3 90 and the C 2 cracker 
392 having inputs and outputs interconnected as illustrated in Fig. 7A. That is, each 

20 component model may be tied to the inputs and outputs of other component models in 
the manner illustrated in Fig. 7A to form the model for the area 382. Of course, the 
models for the other areas 380 and 381 could have other component models having 
interconnected inputs and outputs. These models may be implemented in a processor 
associated with an external data source and provide outputs, such as efficiency, etc. to the 

25 integrated system. Conversely, the models may be implemented within the integrated 
system and receive data from one or more external data sources. 

Referring now to Fig. 7B, the component model for the distillation process 390 
is illustrated in more detail and includes a distillation column 400 having a top portion 
400T and a bottom portion 400B. The input 403 to the distillation column 400 is an 

30 indication of pressure and temperature which may be tied to the output of the model for 
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the preprocessor 388 shown in Fig. 7A. However, this input could be set by an operator 
or be set based on actual measured inputs or variables within the plant 10. Generally 
speaking, the distillation column 400 includes a number of plates disposed therein and 
fluid moves between the plates during the distillation process. CH 4 is produced out of 
the top 400T of the column 400 and a reflux drum 402 feeds back some of this material 
to the top 400T of the column 400. C 2 H 6 generally comes out of the bottom of the 
column 400 andareboiler 404 pumps polypropylene into the bottom 400B of the column 
400 to aid in the distillation process. Of course, if desired, the model for the distillation 
process 390 may be made up of component models for the distillation column 400 the 
reflux drum 402 and the reboiler 404, etc. having the inputs and outputs of these models 
connected as illustrated in Fig. 7B to form the component model for the distillation 
process 390. 

As noted above, the component model for the distillation process 390 may be 
executed aspart of amodel forthe area 382 ormaybe executed separately and apart-from 
any other models. In particular, the input 403 to the distillation column 400 and/or the 
outputs and QH, can actually be measured and these measurements may be used 
wnhin the model of the distillation process 390 in a number of ways as described below. 
In one embodiment, the inputs and outputs of the model of the distillation process 390 
maybe measured and used to determine other factors or parameters associated with the 
model of the distillation process 390<such as the distillation column efficiency,** ) to 
force the model of the distillation process 390 to more accurately match the operation of 
the actual distillation column within the plant 10. The model of the distillation process 
390 may then be used with the calculated parameters, as part of a larger model, such as 
an area orplant model. Alternatively or additionally, the mode! of the distillation process 
390 wath the calculated parameters may be used to determine virtual sensor 
measurements or to determine if actual sensor measurements within the plant 10 are in 
error. The model of the distillation process 390 with the determined parameters may also 
be used to perform control or asset utilization optimization studies, etc. Still further 
component models may be used to detect and isolate developing problems in the plant' 
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10 or to see how changes to the plant 10 might affect the selection of optimization 
parameters for the plant 1 0. 

If desired, any particular model or component model may be executed to 
determine the values of the parameters associated with that model. Some or all of these 
5 parameters such as efE ci ency parameters may mean something to an engineer within the 
context of the model but are generally immeasurable within the plant 1 0. More 
particularly, a component model may be generally mathematically described by the 
equation Y = F(X, P), wherein the outputs Y of the model are a function of the inputs X 
and a set of model parameters P. In the example of the distillation column model of the 

10 distillation process 390 of Fig. 7B, an expert system may periodically collect data (e.g., 
every hour, every ten minutes, every minute, etc.) from the actual plant indicative of the 
actual inputs X to and the outputs Y from the entity to which the model pertains. Then, 
every so often, a regression analysis, such as a maximum likelihood, least squares or any 
other regression analysis may be performed using the model and multiple sets of the 

15 measured inputs and outputs to determine a best fit for the unknown model parameters 
P based on the multiple sets of measured data. In this manner, the model parameters P 
for any particular model may be determined using actual or measured inputs and outputs 
to reconcile the model with the entity being modeled. Of course, this process can be 
performed for any and all component models used within the plant 10 and can be 

20 performed using any appropriate number of measured inputs and outputs. Still further, 
the collected data, or the information calculated from this data, may be provided to the 
data collection and distribution system 1 02 and used in modules reflecting these models, 
the elements modeled by these models, etc. 

In any event, using these component models, or the data collected or generated 

25 by these models, the asset utilization suite 50 can perform asset performance monitoring 
by plotting the values of the determined model parameters) (and/or model inputs and 
outputs) versus time. Still further, the models, whether run in a data source or in the asset 
utilization suite 50, can detect potentially faulty sensors. If one or more of the sensors 
appears to have a high or an otherwise unacceptable error associated therewith, the asset 
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utilization suite 50 can notify a maintenance person and/or a process control operator of 
the faulty sensor. 

Asnoted above, the parameters, inputs, outputs or other variables associated with 
any particular model may be stored and tracked to provide performance monitoring for 
a unit, an area or any other entity of a process or a plant. If desired, two or more ofthese 

variables may be tracked or momtored together to provide a rneasure of me performance 
of the entity. 

. The asset utilization suite 50 can monitor one or more entities based on model 
parameters or other model variables and can report the operating states or performance 
measures ofthese entities to any other desired persons, functions or applications within 
the process control plant 1 0, such as to a process control expert system, a maintenance 
person, a business application, a user interface routine, -etc. Of course, the asset 
utilization suite 50 may perform performance or condition monitoring on any desired 
entity, based on one, two, three or any other desired number of parameters or variables 
for each entity. The identity and number of variables or parameters to be used in mis 
performance monitoring will generally be determined by an expert familiar with the 
process and will be based on the type of entity being monitored. 

If desired, the asset utilization suite 50 or more particularly, the state monitor 

ap P lication240maydefmeaperformancemdexorp]otbycom P arin g oneorrnoreofth^ 
parameters determined by the models as described above with the same parameter 
determined by the model run in accordance with the design parameters of the entity being 
modeled. In particular, the asset utilization suite 50 may execute a model using the 
design parameters of the entity within the plant 10 to which the model pertains to 
determine what the designed performance of the entity would be if it was operating 
according to the current state of the process and using the actual inputs to-the entity as 
measured within the plant 1 0. This design performance can then be compared to the 
actual performance of the entity as determined by the component model for that entity or 
as determined by the measured inputs and outputs of the entity to generate a measure of 
the performance of the entity. 
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The component models may also be used to perform process optimization- In 
particular, the asset utilization suite 50 may use one or more optimization routines which 
execute the individual component models to optimize the operation of the plant in terms 
of some optimization criteria provided by, for example, a process control operator or a 
business person via a business application. The optimizer can be a real time optimizer 
which operates in real time to optimize the plant 10 based on the actual state of the plant 
1 0 at that time. Alternatively or additionally, an optimizer may determine changes to be 
made to the plant 10, such as bringing certain devices or units back on line, that will 
provide the greatest optimization of the plant 10. Of course, other types of optimization 
routines may be executed instead of or in addition to those mentioned here. 

As a result of the above discussion, it can be seen that the use of models provides 
many new types of data or information for the business applications, process control 
applications and asset maintenance and performance monitoring applications. In 
particular, the models can be used to perform performance monitoring and to produce a 
performance index which indicates the relative performance of a device, unit, area, etc. 
within a plant. This performance index maybe a measure of the performance of an entity 
with respect to the possible performance of that entity. Furthermore, while device and 
unit models have been discussed above, similar models could be made and executed for 
process control entities, such as loops, units, etc. to provide performance measures and 
optimization criteria for these types of entities as well. Also, as indicated above, models 
may, in some cases, be used to measure or indicate the health of certain devices or other 
entities and to provide a health index indicative of these entities. For example, the error 
measurements of certain input and output sensors as determined by the regression 
analysis used on certain models may be used as or converted into an indication of the 
health of those devices. Also, other information not otherwise available to the process 
controller, such as model parameters and virtual sensor measurements based on the 
models could be provided to the process controllers or to the business persons for use in 
numerous manners. 

Besides performance and health indexes, the asset utilization suite 50 can assist 
the index generation routine in creating other types of indexes such as a utilization index 
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and a variability index. A variability index indicates how much some signal into or out 
of, or some other parameter associated with a device, loop, unit, etc. varies as compared 
to how much this signal or parameter is expected to vary. The data needed <o create this 
vanability index may be collected by the asset utilization suite SO via the dat* collection 
and distribution system 1 02 and provided to the index generation routine at any desired 
orconvenienttimes. Of course, the normal amount of variation of a signal ox parameter 
maybe set by a manufacturer, engineer, operator or maintenance person familiar with the 
entry or may be based on a statistical measure (such as an average, standard deviation, 
etc.) associated with that or other similar entities within the plant and this normal or 
expected variation may be stored by or updated within the index generation routine 

The utilization index, in one form or another, tracks or reflects the utilization of 
mdrvadual loops or other entities and may provide some indication as to whether these 
entities are being utilized based on previously determined bench marks or operational 
goals. A utilization index can be generated based on measured uses of the actual device 
For example, a device may be measured as to how often it is being used within a process 
compared to a desired utilization. The utilization index might identify lo ops, etc. which 
are not being used as designed. 

A* indicated above, the user interface routine 244 provides a graphical user 
tnterface (GUI) tha, is integrated with the asset utilization suite 50 described herein*, 
factbtate a user's interaction with the various asset uulizationcpabi. .ties provided by .he 

asset utih-zationsuheSO.However.beforediscussinguteGWingrea.crde.aU.i.shouid 
be recognized tha, the GUI may inc.ude one or more software routines that are 
tmplemented using any suitable programming languages and techniques. Further the 
software routines making up ,he GUI may be stored and processed within a single 
processmg stimon or unit, such as, for exampte, a workstation, a controUer.etc witmn 
the plant 10 or. alternatively, the software routines of the GUI may be stored and 
executed it, a distributed manner using a plntaUty of processing mute mat are 
communicatively coupled to each otherwimin the asset utilization system. Still further 
the data used by the GUI to create certain screens may be accessed ft™ externa, data 
sources via the data collection and distribution system 102. 
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Preferably, but not necessarily, the GUI may be implemented using a familiar 
graphical windows-based structure and appearance, in which a plurality of interlinked 
graphical views or pages include one or more pull-down menus that enable a user to 
navigate through the pages in a desired manner to view and/or retrieve a particular type 
5 of information. The features and/or capabilities of the asset utilization suite 50 described 
above may be represented, accessed, invoked, etc. through one or more corresponding 
pages, views or displays of the GUI- Furthermore, the various displays making up the 
GUI may be interlinked in a logical manner to facilitate a user's quick and intuitive 
navigation through the displays to retrieve a particular type of information or to access 

10 and/or invoke a particular capability of the asset utilization suite 50. 

In one embodiment, similar to Fig. 5 above, the GUI may perform or present a set 
or series of hierarchical displays in which more basic or common information about the 
nature of the process control system (such as the areas, loops, devices, controller routines 
performance monitoring applications, etc. within the plant) is displayed in some manner 

15 in a higher level display. Then, in a series of subsequent lower level displays, which may 
be accessed by selecting and clicking on any of the particular information within the 
higher level display, may provide further information about the control routines, the 
maintenance routines, the interconnections of process control equipment, as well as 
actual performance measurements, process control routine activity such as alarms, 

20 problems, etc., performance measurements such as performance recommendations, 
predictions, etc. and maintenance information such as problems occurring within the 
plant etc. Other lower-level displays may then provide further information about 
elements in those displays. In general, such a hierarchical display provides more 
information about particular areas, loops, etc. and the problems associated therewith from 

25 the standpoint of process control activities, maintenance activities as well as process 
performance activities as the user drills down or go into lower levels in the display. 

Generally speaking, the GUI described herein provides intuitive graphical 
depictions or displays of process control areas, units, loops, devices, etc. Each of these 
graphical displays may include numerical status and performance indexes (some or all 

30 of which may be generated by the index generator routine described above) that are 
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associated with * particular view being displayed by the GUI For exampte, a display 
dep.chng a process con<rol area may prov.de a sel obexes reflecting me status and 
perfonnance of fta, area (i.e., a particular portion of the prt.cesscon.ro. system a, a 
particular leve! of «ne equipmen, hierarchy). On ,be other hand, a display depicting a 
loop may provide a « of status and performance indexes associate with tha, particute 
loop, m any even,, a user may use Ore indexes show, within any view, page or display 

to quicklyassesswhenteraptoblemexi^wiUtinanyofthedevicesJoops.e.c. depict 
within that display. 

Additionally, the GUI described herein may automatically, or may in response to 
lu a request by a user, provide maintenance information to the user. The maintenance 
mfotmation maybe provided by any portion of the asset notation suite 50. Simi ,arly 

beprovtdedbyfteassetutilizationsuite^O.Stiniurther.meGUImayprcvidemessages 
to the user in connection with a problem ma, has occuned or which may be about ,o 
occur within me plan, 10. These messages may include smphiea. and/or textual 
mformation tha, describes *e problem, suggest possible changes ,o «he system which 
may be implement to aUeviate a cutren, problem or which may be implemented ,o 
avo,d a potential problem, describes courses of action ma, may be pursued ,o correct or 
to avoid a problem, etc. 

Still finther, me GUI describee herein may automatically, or in response to a 
request by a user, provide process performance information to the user. The process 
performance information may be provided by any portion of Ure asse, utilization suite 50 
Such perfonnance date or information may incmde performance measures, predictions 
or recommendations ,o tire user about changes to ,he process to alter «be perfomnmce 
may mclude inputting or: displaying <he perfonnance goals cunently being used by the' 
system etc. 

Fig. 8 is an exemplar depiction of a display representing a uni, 500 within a 

^^'^tomaybemsplayedbymeGUI.AsiHusn^mFig.g.meunit 
500 mcludes a p!^ of devices such as, for exam pI e. valves, pumps, tempemmm 
transmmers, etc., all of which maybe depicted gmphicanyas shown. Additionally, me 
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' display may further include lines arrows, and any other indicia to represent logical and 
physical interconnections between the various devices. Of course, such graphical 
representations of process control systems (or portions of process control systems) are 
well known in the art and, thus, the manner of implementing these graphical 
5 representations or displays will not be described in further detail herein. 

The GUI display shown in Fig. 8 also includes a plurality of index names and 
values 550. In particular, the index names and values 550 include a performance index, 
a health index, a variability index and a utilization index, all of which have been 
discussed briefly above in connection with the asset utilization suite 50 and the index 

10 generation routine thereof The index names and values 550 may be displayed in a 
tabular format as shown or in any other desired format. The index names and values 550 
are representative of the performance and status of the entire unit 500 and, thus, the index 
values shown are preferably, but not necessarily, composed of the index values or fields 
associated with each of the sub-units and/or devices that make up the unit 500. 

15 Before discussing the GUI and the manner in which asset information, process 

control information, maintenance information, diagnostic information, performance 
information or any other type of information is displayed to a user thereby, a brief 
discussion of the manner in which the performance and status indexes are generated is 
provided below. Also, it should be recognized that while a performance index, a health 

20 index, a variability index and a utilization index are described in detail herein in 
connection with the various displays of the GUI, additional and/or different indexes may 
be generated by the asset utilization suite 50 and displayed via the GUI. It will also be 
understood that some or all of the data displayed by the GUI may come from an external 
data source. 

25 In general, the indexes generated by the index generator routine and displayed via 

the GUI maybe calculated for individual devices, for logical and/or physical groupings 
of devices, for logical processes (e.g., control loops), for logical groupings of process 
equipment such as units and areas, etc. In other words, the indexes may, in principal, be 
calculated at each level of the equipment and logical hierarchy of a process control 

30 system or, more generally, an asset utilization system, which may include one or more 
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processcontrol systems. However, *e meaning ofa particular index may depend on the 
context (Le., whether the index corresponds to a logical or a physical grouping of devices 
and/orparameters) in which the index is generated and displayed and may depend on the 
level of the hierarchy at which it is displayed. For example, a, the lowest level of the 
5 eqummentfcerarchy, indexes correspond tophysical devices such as valves, temperature 
sensors, actuators, etc. Thus, each device may have a unique set of indexes that may be 
generated within the device or for the device based on information stored within the 
device at the time the device is manufactured. Accordingly, each device may generate 
and provade its indexes to higher levels of the hierarchy and to the asset utilization suite 
10 50 as needed. 

Similarly, units or loops, each of which is composed of one or more devices or 
funcnon blocks may each have a unique set of indexes. Of course, the calculation of one 
or more of the performance, health, variability and utilization indexes may not be 
appropnate, required or useful for every level of the logical andequipment hierarchies 
15 Any or all of these indices may be indicative of the health of a device or other entity 
wathm the system. For example, the health index (HI) for a device may be based on 
historical usage of the device. In particular, the device manufacturer may store 
^formation relating to the life cycle of the device within the device and, based on -the 
usage of the device and the environmental impacts imparted -to the device during its 
O operanon (e.g., temperature variations, shocks, etc.), the device may determine to what 
extOTt ^evi«hasmoved^ 

program a device to provide an HI value which is indicative of the current status of^he 
hfe cycle of the device. For example, a stroke type valve may have an expected useful 
operatmglifecycleof250,000mllstrokecyclesandmemanufactur^ 
> devace, which is typically a smart field device, has stored in its memory the expected 

numberoflifetimeoperatingstrokesalongwimmecu^entnu^^ 
has completed. Thus, in the case where an HI value may range from good, need 
mamtenance soon (NMS) and need maintenance now (NMN), the HI value generated 
may be based on the number of strokes ranging from zero to 250,000. Of course the 
prease relationship between the HI values and the lifecycle characteristic<e.g., strokes) 
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may not be linear. To the contrary, many life cycle characteristics follow an exponential 
characteristic, whereby J f^iiife ::? ^and degradation in device performance/operation 
progresses more rapidly as time passes, as strokes are completed, etc. Of course, there 
are many other manners of defining or computing an HI for a device, based on the current 
5 detected state of the device and how well it is operating. The HI for a loop, on the other 
hand, is preferably, but not necessarily, based on functions blocks that make up the loop. 

Similarly, the UI calculated for the loop, area and unit levels, represents the 
degree to which a particular asset (e.g., a loop) is being exploited in comparison to its 
capacity or desired utilization. For example, the UI value may be based on the amount 

10 of time for which loops are being used to perform control as designed. 

Fig. 9 is an exemplary graphical display that may be provided by the GUI to 
enable a user to quickly analyze the operational status and performance of a process area 
within the plant 10. As shown in Fig. 9, the GUI may graphically depict the physical 
equipment (and the interconnections therebetween) within a process area 600. Of course, 

15 it should be recognized that although a process area is depicted within the GUI display 
shown in Fig. 9, any other portion of the plant 1 0 such as, for example, a unit, sub unit, 
loop, device, etc. may be shown instead to achieve the same or similar results. In any 
event, the process area 600 is depicted as having a pair of tanks, a plurality of temperature 
transmitters, pressure transmitters, flow transmitters, etc. and pipes, all of which maybe 

20 interconnected as shown in Fig. 9. Further, each of the physical devices maybe displayed 
along with an associated alphanumeric identifier (e.g., TT-394) that uniquely identifies 
that device within the plant 10 and may also be displayed along with a graphic meter or 
gauge (i.e., the partially shaded semi-circular features) that enables a user to quickly 
determine the status of the sensing parameter associated with that device. For example, 

25 the GUI may display a graphic meter or gauge associated with a temperature transmitter 
and may shade more or less of the meter based on the temperature currently being sensed 
by the temperature transmitter. Importantly, one or more of the VI, HI, UI and PI values 
may be displayed for one or more of the devices shown within the area 600. By way of 
example only, the HI values for several of the devices that are connected to a tank 610 

30 within the area 600 are displayed. However, more or fewer HI values could be displayed 
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if desired. Additionally, different index values or groups of index values may he 
displayed for any of the devices that appear within the area 600 as desired. As can he 
appreciated from the display shown in Fig.9,auser can quicklyascertain whether an area 
is performing properly and wiU continue to perform properly. Further, a userean also 
• . ^ icU y*e n tifyt^^ 

may be causing a particular problem. 

It will also be understood that a user may view successively lower and lower 
entities within a plant and be provided information about the indexes associated with 
each of these different entities or views. Thus, for example, a user may look at a view 
of the plant and see a particular set of indexes for the plant. The user may then focus on 
one area, such as by clicking on one of the areas within the plant view, and see .the 
indexes associated with that area. Similarly, by clicking on units within the displayed 
area, the indexes for different units may be viewed. Likewise indexes for loops, sub 
units, devices etc. may then be viewed by focusing in on these different entities from a 
view of an entity in which these entities are located. In this manner, a usercan quickly 
find the cause of a lower than (or higher than) expected index at any point or level of the 
Plant. Of course, some of the displayed data for the system is based on or developed • 
from data received from external data sources via the data collection and distribution 
system 102. 

Fig. ] 0 is an exemplary depiction of a display that may be provided by the GUI 
to enable a user to view audit trail information ^connection with any device used within 
the area 600. By way of example, a user may use a mouse to click on a given device or 
its alphanumeric identifier or, alternatively, may enter the identifier via a keyboard, to 
request a pop-up audit trail window 6S0 for that device. In this manner, a user can use 
the audit trail information to determine whether an improper or unacceptable index value 
may be related to a failure to calibrate the device properly or in a timely manner, whether 
a device has been configured properly or at all, etc. 

Fig. 11 is an exemplary depiction of a display that may be provided by the GUI 
to enable a user to perform a more detailed analysis of the data which may he used in 
generating one or more of the indexes for a particular device within<he area 600 or*o 
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perform condition monitoring. By way of example only, a vibration analysis for a motor 
675 may be displayed in a pop-up window 680. A user may request such a pop-up 
window in response to an abnormally high or an abnormally low index value for the unit 
affected by the motor 675 and/or may request the window if an index value associated 
with the motor is indicative of a possible problem. Furthermore, if desired, the GUI may 
automatically provide such pop-up windows containing a detailed data analysis for those 
devices, units, etc. that have one or more abnormal index values. 

Fig. 12 is yet another exemplary depiction of a display that may be provided by 
the GUI to enable a user to quickly investigate alarm information, conditions* etc. within 
the plant 10. A high level graphical view 750 of the plant 10 may include an alarm 
banner 760 having one or more pending alarms. Each of the alarms within the alarm 
banner may be represented using an alphanumeric indicator that is uniquely associated 
with the device or other entity which generated the alarm or event Additionally, each 
of the alarms within the banner 760 may also include an information button 770, which 
may be selected by a user to generate a pop-up window 775 containing more detailed 
information relating to that particular alarm. Further, the user may also select the 
alphanumeric designator for the device causing a particular alarm to investigate the 
possible reasons for the alarm. When the alphanumeric designator is selected, a pop-up 
window 780 may be provided by the GUI. The pop-up window 780 may provide one or 
more response categories 785, which may facilitate the user's understanding of how a 
particular alarm should be addressed and within what time frame the alarm should be 
addressed. By way of example, the pop-up window 780 may indicate that a particular 
device is no longer communicating, that the device has failed, that the device needs 
maintenance immediately, or that the device requires maintenance or some other attention 
soon. Of course more, fewer and/or different response categories may be used instead. 
The alarm display generated by the GUI at this point may be the integrated display 
disclosed in U.S. Patent Application Serial Number 09/707,580 (filed November 7, 2000) 
which is hereby expressly incorporated by reference herein. Generally, this alarm display 
may show process alarms and alerts as well as other types of alarms like maintenance 
alarms and alerts. Still further, process performance alarms may be displayed to show 
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alarms related to poor process performance. Furthermore, information about the alarm, 
such a specific information provided in the field 775 of the aJarm banner may be sent to 
meGUIortomeassetutilizarionsuiteSOalongwmmealarm. As will be understood, 
the alarm and alert information may come from external data sources in the manner 
indicated above with respect to Figs. 3-6. 

Figs. 13 and 14 depict further displays which may be produced by the GUI to 
provide additional information related to control performance, control utilization,device 
health or process performance. In particular, referring toFig. 1 3, the left-hand side shows 
a tree structure having hierarchical information about the processcontrol plant, including 
a DeltaV system (which is a controller system), an "Area A,'* a "Pro-Plus" area as well 
as additional higher level elements within the process control plant Selecting some of 
these elements such as DeltaV system will provide further information related -to the 
devices or control systems or other performance characteristics of the selected element. 
On the right-hand side of Fig. 13, an expert engine has collected and displayed 
information regarding diagnostics of the selected DeltaV system including the number 
of modules (in this case 42) which are within the incorrect mode, the number of modules 
which have exhibited limited control, the number of modules having had input/output 
problems and the number of modules having large variability. Again, the data used to 
create this screen may come from external data sources through the data collection and 
distribution system described herein. Still further, control performance, control 
utilization, device health and process performance measures developed from one or more 
of the control data, device data and performance data are illustrated at the bottom of the 
display of Fig. 12. 

Referring to Fig. 14, more information about the same system in terms of the 
modules with bad input/output is displayed as another lower level display. Here the right 
side of the display shows particular module names and the percentage of time each has 
had bad input. This screen also shows a list of alarms generated and, in particular, that 
analarmforablockAIl exists as the block All is having bad input 100% of the time. due 
to a device failure. This display also illustrates that thedevice needs maintenanoe«soon. 
Of course these and other types of user interface screenscould be provided for any or all 
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of the information pertaining to device health, variability, status, etc. The displays of 
Figs. 13 and 14 may be generated by a diagnostic control routine such as that disclosed 
in the U.S. Patent Application Serial Numbers 09/256,585 and 09/499,445. 

Fig. 1 5 is still another exemplary depiction of a display that may be provided by 
the GUI which enables a user to track work orders which may have been automatically 
generated by the work order generation routine 270. The asset utilization suite 50 may 
provide data to the work order generator routine 270 which causes that routine to 
automatically generate work orders in response to a problem or potential problem 
discovered or recognized by the asset utilization suite 50 and/or a user working with the 
asset utilization suite 50 via the GUL For example, the asset utilization suite 50 may 
receive diagnostic information, maintenance requests, etc. from internal and external data 
sources and, in response, may cause the maintenance system to generate a work order that 
requests a maintenance person to attend to one or more problems in connection with the 
diagnostic information. Of course, the specifics of the work order generated will depend 
on the type of problem or situation detected and the standard forms used to correct the 
problem, such as ordering parts, supplies, etc. 

Still further, the work order generation routine 270 could include a business to 
business communication function that, based on detected actual or predicted problems 
within the plant 10, will automatically communicate with a supplier or other business to 
order parts, supplies, etc. with or without operator or maintenance person intervention. 
More particularly, the routine 270 can receive notifications of current problems or 
predicted future problems with devices or other assets based on data provided by or 
predictions made by the asset utilization suite 50 or any of the data analysis tools, such 
as the rotating equipment analysis tools. The routine 270 then automatically contacts a 
supplier via, for example an internet, telephone or other communication connection and 
orders the parts, equipment or supplies to be delivered to the plant 10 before the device 
needs to be replaced. In this manner, the work order generation routine 270 limits the 
down time or helps to assure that there is little or no down time caused by the need to 
wait for parts, equipment or supplies to fix the problem when it actually occurs. This 
fact, then makes the plant 1 0 more efficient. 
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Referring now to Fig. 1 6, the GUI can provide other screens to a user to indicate 
current or future problems, such as predicted problems, which can be detected by the 
asset utilization suite 50 or any of the data analysis tools within the plant lOsuchasdata 
analysis tools associated with remote data sources. In particular, Fig. 16 illustrates a 
. display showing spectral plots of vibration of an element, such as a shaft, within a rotary 
device performed by the vmration analysis programs 23 of Fig. 1 and conditions or 
problems detected by the analysis tool based on these plots. Of course other conditions 
for rotary or other devices based on the results of data analysis tools can also be 
displayed. Still further, the results of these tools can be used to cause the work order 
generation routine 270 to automatically order replacement parts and/or to order or 
schedule work (such as repair or maintenance) to be performed within the plant 10. 

While the data collection and distribution system 1 02 and the asset utilization 
suite 50 and otherprocess elements have been described as preferably being implemented 
m software, they may be implemented in hardware, firmware, etc., and may be 
implemented by any other processor associated with the process control system 10. Thus, 
the elements described herein maybe implemented in a standard multi-purpose CPU or 
■ on specifically designed hardware or firmware such as an application-specific integrated 
circuit (ASIC) or other hard-wired device as desired. When implemented in software, the 
software routine may be stored in any computer readable memory such ason a magnetic 
<hsk, a laser disk, or other storage medium, in a RAM or ROM of a computer or 
processor, in any database, etc. Likewise, this software may be delivered to a user or a 
process control plant via any known or desired delivery method including, for example 
on a computer readable disk or other transportable computer storage mechanism or ov* 
a communication channel such as a telephone line, the internet, <*c. <which are viewed 
as being the same as or interchangeable with providing such software via a transportable 
storage medium). Also, while the suite 50 is described as possibly being or using a nOe- 
based expert, other types of expert engines could be used as well, including those which 
use other known data mining techniques. 

Thus, while the present invention has been described with reference Ao specific 
examples, which are intended to be illustrative only and not to be limiting of the 
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invention, it will be apparent to those of ordinary skill in the art that changes, additions 
or deletions maybe made to the disclosed embodiments without departing from the spirit 
and scope of the invention. 

In the present specification "comprises" means "includes or consists of 1 
and "comprising" means "including or consisting of. 

The features disclosed in the foregoing description, or the following 
claims, or the accompanying drawings, expressed in their specific forms or in 
terms of a means for performing the disclosed function, or a method or process 
for attaining the disclosed result, as appropriate, may, separately, or in any 
combination of such features, be utilised for realising the invention in diverse 
forms thereof. 
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CLAIMS 



1 . A process control system within a plant including: 

process equipment monitoring devices that collect equipment data; 
process control monitoring devices that collect process control data; 
process models adapted to perform process performance monitoring to 
generate process performance data; and 

a computer system that implements a software routine that uses two or 
more of the equipment data, the process control data and the process 
performance data to perform a function within the plant. 

2. The process control system of claim 1, wherein the^unction within the 
plant is a diagnostic function and the software routine is a diagnostic routine 
that combines two or more of the equipment data, the process control data and 
the process performance data to perform a diagnostic function. 

3. The process control system of claim 2, wherein the -software routine 
includes two or more of a process control diagnostic routine, an equipment 
monitoring diagnostic routine and a process performance diagnostic routine. 

4. The process control system of claim 3, wherein the software routine 
includes two or more of a process control model, an equipment model and a 
performance monitoring model. 

5. The process control system of any one of claims 2 -to 4, wherein the 
diagnostic routine includes a predictive routine that predicts a condition in the 
future based on two or more of the equipment data, the process control data and 
the process performance data. 

6. The process control system of any one of claims 2 to 5, further including 
a recommendation so We routine which makes recommendations t-o a user in 
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response to a diagnostic decision made by the diagnostic routine. 

7. The process control system of any one of claims 2 to 6, further including 
an action software routine which implements one of a control action or a 
process action based on a diagnostic decision made by the diagnostic routine. 

8. The process control system of any one of claims 2 to 7, further including 
an order generating routine which automatically generates an order based on a 
diagnostic decision made by the diagnostic routine. 

9. The process control system of claim 8, wherein the order generating 
routine generates a work order ordering work to be performed within the plant. 

10. The process control system of claim 8 or claim 9, wherein the order 
generating routine generates a part order ordering one or more parts needed for 
the plant. 

11. The process control system of any one of claims 2 to 10, wherein the 
diagnostic routine performs backtracking based on two or more of the process 
control data, the equipment data and the process performance data. 

12. The process control system of any one of the preceding claims, wherein 
the function is a viewing function and the software routine is adapted to create 
and display a display screen via a display terminal using two or more of the 
collected equipment data, the process control data and process performance 
data. 

13. The process control system of claim 12, wherein the software routine 
includes an index creation routine that creates indexes associated with process 
control components or with equipment components or process performance 
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components and wherein the software routine creates a view of the 
control plant displaying the indexes. 



14. The process control system of claim 12 or olaim 13, wherein 4he 
software routine displays process two or more of a process control alarm, an 
equipment alarm and a process performance alarm together on a display screen. 

15. The process control system of any one of the preceding elaims, further 
including one or more data reconciliation applications which process the 
collected equipment data or the collected process control data or the process 
performance data. 

16. The process control system of claim 15, wherein the equipment data or 
the process control data or the process performance data is compressed. 

1 7. The process control system of any one of the preceding claims, wherein 
the software routine is distributed among two or more -computers within the 
plant. 

18. A process control system substantially as hereinbefore described with 
reference to and/or as shown in the accompanying drawings. 

1 9. A method of operating a process control system within a plant including 
the steps of: ; 

collecting equipment data related to the status of equipment within the 

plant; 

collecting process control data related to the status of proeess -control 
activities within the plant; 

collecting process performance data relating to the performance of the 
process; and 



using two or more of the equipment data, the process control data and 
the process performance data to perform a further function within the plant. 

20. The method of claim 19, wherein the further function within the plant is 
a diagnostic function and the step of using two or more of the equipment data 
and the process control data and the process performance data includes the step 
of combining two or more of the equipment data and the process control data 
and process performance data to perform a diagnostic function. 

21. The method of claim 20, wherein the step of combining two or more of 
the equipment data and the process control data and the process performance 
data includes the steps of using two or more of a process control diagnostic 
routine to process the process control data, an equipment monitoring diagnostic 
routine to process the equipment data and a process performance monitoring 
routine to process the process performance data. 

22. The method of claim 21, wherein the step of combining two or more of 
the equipment data and the process control data and the process performance 
data includes the step of using two or more of equipment models, process 
control models and process performance models. 

23. The method of any one of claims 20 to 22, wherein the step of 
combining two or more of the equipment data and the process control data and 
the process performance data includes the step of predicting a condition in the 
future based on two or more of the equipment data and the process control data 
and the process performance data. 

24. The method of any one of claims 20 to 23, further including the step of 
recommending one or more actions to a user in response to a diagnostic 
decision made during the step of combining two or more of the equipment data 
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and the process control data and the process performance data. 

25. The method of any one of claims 20 to 24, further including the step of 
implementing one of a control action or a process action based on a diagnostic 
decision made during the step of combining two or more of the equipment data 
and the process control data and the process performance data. 

26. The method of any one of claims 20 *> 25, further including 
automat JC ally generating an order based on a diagnostic decision made during 
the step of combining two or more of .the equipment data and the process 
control data and the process performance data. 



27. The method of claim 26, wherein the order generating step generates 
work order ordering work to be performed within the plant. 



a 



28. The method of claim 26 or claim 27, wherein the order -generating step 
generates a part order ordering one or more parts needed for the plant. 

29. The method of any one of claims 20 to 28, wherein the step of 
combining two or more of the equipment data and the process control data and 
the process performance data includes the step of performing backtracking 
based on two or more of the equipment data and the process control data and 
the process performance data. 

30. The method of any one of claims 19 to 29, wherein the function is a 
viewing function and the step of using two or more of the equipment data and 
the process control data and the process performance data includes the step of 
creating a display screen using two or more of the collected equipment data and 
the process control data and the process performance data. 
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31. The method of claim 30, wherein the step of using two or more of the 
equipment data and the process control data and the process performance data 
includes the step of creating one or more indexes associated with process 
control components or with equipment components or with process 
performance components and wherein the step of creating a display screen 
includes the step of creating a view of the process control plant displaying the 
one or more indexes. 

32. The method of claim 30 or claim 31, wherein the step of creating a 
display screen, includes the step of displaying two or more of a process control 
alarm, an equipment alarm and a process performance alarm together on the 
display screen. 

33. The method of any one of claims 19 to 32, further including the step of 
processing the collected equipment data or the collected process control data or 
the process performance data prior to the step of using two or more of the 
equipment data and the process control data and the process performance data. 

34. The method of any one of claims 19 to 33, further including the step of 
compressing at least a portion of the process control data or the equipment data 
or the process performance data. 

35. A method of operating a process control system substantially as 
hereinbefore described with reference to and/or as shown in the accompanying 
drawings. 

36. A process control system comprising: 
multiple process control devices; 
one or more controllers; 

one or more user interfaces; 
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one or more data collection routines implemented on processing devices 
that collect process control data, equipment data and process performance data; 
and 

a condition monitoring routine communicatively connected to the data 
collection routines to accept and process the process control data, the 
equipment data and the process performance data •collected by the <Jata 
collection routines to perform condition monitoring within the process control 
system; 

wherein the process control devices, controllers and user interfaces are 
communicatively connected via one or more communication networks and 
wherein the data collection routines are configured to transparently accept data 
from multiple different source types within the process control system. 

37. The process control system of claim 36, wherein the multiple different 
source types includes two or more of hand held collection devices, laboratory 
chemical and physical measurement sources, direct on-line input sources and 
remote sources. 

38. The process control system of claim 36 or claim 37, wherein the process 
control system is distributed across a geographically distributed network. 

39. The process control system of claim 38 wherein at least one of the 
communication networks is a shared communication channel comprising one of 
me internet or a satellite communication network. 

40. The process control system of claim 38, wherein the data collection 
routines collect data via a physical medium comprising one of wired, wireless, 
coaxial cable, telephone modem, fiber optic, optical, meteor burst, satellite 
medium using one of a Fieldbus, IEEE 802.3, blue tooth, X.2S or X.400 
communication protocol. 
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41. The process control system of any one of claims 36 to 40, wherein the 
data collection routines operate independently and communicate with each 
other via the one or more communication networks. 

42. The process control system of any one of claims 36 to 41, wherein each 
of the data collection routines includes a data processing routine that reconciles, 
verifies, validates and formats the collected data in a consistent format. 

43. The process control system of any one of claims 36 to 41, wherein the 
data collection routines send the collected data to a control system using one of 
the controllers and one of the user interfaces and wherein the condition 
monitoring routine reconciles, verifies, validates and formats the collected data 
in a consistent format. 

44. The process control system of claim 43, wherein the condition 
monitoring routine is stored and executed on a subassembly processor 
associated with the control system. 

45. The process control system of claim 44, wherein the subassembly 
processor is connected directly to the user interface and the controller of the 
control system via a system bus. 

46. The process control system of claim 44, wherein the controller includes 
an input/output system adapted to connect the controller of the control system 
to process control equipment and wherein the subassembly processor is 
integrated with the controller input/output system. 

47. The process control system of claim 46, wherein the data collection 
routines include a compression routine that compress the collected data. 
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48. The process control system of claim 41, wherein the compression 
routine uses a compression technique comprising one of wavelet signal 
representation, Fourier, Hadamard transformation and communication of «he 
coefficients, exception processing, and swinging door data compression. 

49. A process control system substantially as hereinbefore described with 
reference to and/or as shown in the aecompanying drawings. 

50. A process control system comprising: 
multiple process control devices; 
one or more controllers; 

one or more User interfaces; 

a communication network that interconnects the one or more controllers 
and the one or more user interfaces; 

a database that stores equipment and process control strategy 
configuration information pertaining to the configuration of the process confeol 
system; 

one or more data collection routines implemented on processing devices 
that collect process control data, equipment data and process performance data; 

a condition monitoring routine communicatively connected to the one or 
more data collection routines to accept and process the process control data the 
equipment data and the process performance data collected by the data 
collection routines to perform condition monitoring within the process control 
system; and 

a display routine that displays the equipment and process control 
strategy configuration information associated with the process control system as 
stored in the database along with condition monitoring information pertaining 
to or generated by the condition monitoring routine, via the one or more user 
interfaces. 
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51. The process control system of claim 50, wherein the display routine 
displays the equipment and process control strategy configuration information 
and the condition monitoring information in multiple levels, including a high 
level presenting information pertaining to different elements of the equipment 
and process control strategy and one or more lower levels providing more 
information about individual elements within the high level including condition 
monitoring information. 

52. The process control system of claim 51, wherein the display routine 
enables a user to go from a higher level layer to a lower level layer by selecting 
an element within a screen depicting the higher level layer. 

53. A process control system substantially as hereinbefore described with 
reference to and/or as shown in the accompanying drawings. 

54. Any novel feature or novel combination of features described herein 
and/or in the accompanying drawings. 
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